Replies: 6 comments
-
|
"I understand the pain, but I disagree on the prescribed medicine." By hypothetically creating a FATAL code, we would be inviting FAILs to be more broadly ignored. Also, at some point FATALs would also affect old font families. So, we'r eprone to face the same problem again in the short term. In my opinion, a better solution would be to put in place mechanisms for documenting exceptions for eventual FAILs, and making the CI job ignore those FAILs that have explicit excuses documented. |
Beta Was this translation helpful? Give feedback.
-
|
Did we find a solution to this issue? imo it's a quite important to solve. |
Beta Was this translation helpful? Give feedback.
-
|
Based on the chat conversation where this option was initially discussed, the FATAL log-level result would be related to issues that would break the pipeline workflow, not directly or necessarily to font binaries. Similar to the So, it could work like this:
|
Beta Was this translation helpful? Give feedback.
-
|
OK. I will make an initial implementation. Could you please list here which checks would be the first ones to be changed from |
Beta Was this translation helpful? Give feedback.
-
|
The last one that initiated this com.google.fonts/check/metadata/parses) reported here. |
Beta Was this translation helpful? Give feedback.
-
|
We did this. |
Beta Was this translation helpful? Give feedback.
-
I'd like a new check status which is even more severe than FAIL. It should be named something like FATAL! This status should be used for checks which are essential for a family to successfully get onboarded to Google Fonts such as metadata files parsing correctly.
Implementing this check status will allow me to finally set the google/fonts ci to fail. I don't want to raise error codes on just FAILs since they are too strict and will fail many older families.
Discussion triggered by google/fonts#7078
cc @chrissimpkins
Beta Was this translation helpful? Give feedback.
All reactions