Not sure if this is a JetBrains Mono specific issue or a fontbakery wide issue... @RosaWagner I see you've set up the CI workflow, hopefully you'd be able to help with this or could point to someone? :)
I've been working on a spin-off of JBMono and using the CI quite a lot for QA and build. However, it's been failing on every checks lately, all with the same error on the com.google.fonts/check/metadata/escaped_strings check.
I created a clean fork of JetBrainsMono just to check it wasn't an issue that I might've introduced, CI failed on that same check too...
Full log:
https://github.com/wayne-shih/JBMono-CI-Check/pull/2/checks?check_run_id=1446635871#step:7:183
Snippet:
>> Check: com.google.fonts/check/metadata/escaped_strings
Desc: Ensure METADATA.pb does not use escaped strings.
Files: JetBrainsMono-MediumItalic.ttf
* ERROR: Failed with TypeError: expected str, bytes or os.PathLike object, not NoneType
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/checkrunner.py", line 366, in _exec_check
for sub_result in result: # Might raise.
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/profiles/googlefonts.py", line 4911, in com_google_fonts_check_metadata_escaped_strings
for line in open(metadata_file, "r").readlines():
Result: ERROR
I did some digging... nothing new was introduced to @f-actions/font-bakery that might be causing it that I could tell. So that led to me looking into the fontbakery repo itself. Looks like the escaped_strings metadata check was introduced to the v0.7.32 release (changelog here)
And that check was created as a result of issues https://github.com/googlefonts/fontbakery/issues/2932 and https://github.com/googlefonts/gftools/issues/211
โย โ
Sum it all up, does this mean a METADATA.pb file needs to be introduced to the JetBrains Mono repo to resolve any future CI check fails on this repo?
...or would it mean there can't be any special characters in the metadata fields and thus some of the current fields would need to be changed as it contains brackets, slashes... (like in the copyrights, and licenses fields) (if those characters are even considered escape strings in this case?)
I have no idea. When it's an error, it is often the tool itself the problem. Please open an issue in Fontbakery issue tracker, @felipesanches is very reactive and helpful :)
Sum it all up, does this mean a METADATA.pb file needs to be introduced to the JetBrains Mono repo to resolve any future CI check fails on this repo?
Hope not.
This sounds like a bug in fontbakery. I will try to fix it quickly so that you can resume your work without further disruptions. Thanks for reporting the problem!
some other people are observing the same problem as reported at https://github.com/googlefonts/fontbakery/issues/3095
The problem is fixed and I made an emergency FontBakery v0.7.33 release now including the fix. Please only close this issue after you ensure your setup is working nicely again.
whoop whoop! thanks for the speedy fix @felipesanches! really appreciate it!
ERROR: 0 ๐ง ๐ ๐
โ
that was for the static fonts, now for variable...
I'm now getting errors for these checks
metadata/gf-axisregistry_bounds
metadata/gf-axisregistry_valid_tags
metadata/consistent_axis_enumeration
I'm assuming these would be in a similar situation as the previously fixed metadata/escaped_strings where I don't have METADATA.pd in the repo in which CI workflow is being run?
>> Check: com.google.fonts/check/metadata/gf-axisregistry_bounds
Desc: Validate METADATA.pb axes values are within gf-axisregistry bounds.
Files: WynyardMono[wght].ttf
* ERROR: Failed with AttributeError: 'NoneType' object has no attribute 'axes'
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/checkrunner.py", line 366, in _exec_check
for sub_result in result: # Might raise.
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/profiles/googlefonts.py", line 4706, in com_google_fonts_check_gf_axisregistry_bounds
for axis in family_metadata.axes:
Result: ERROR
>> Check: com.google.fonts/check/metadata/gf-axisregistry_valid_tags
Desc: Validate METADATA.pb axes tags are defined in gf-axisregistry.
Files: WynyardMono[wght].ttf
* ERROR: Failed with AttributeError: 'NoneType' object has no attribute 'axes'
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/checkrunner.py", line 366, in _exec_check
for sub_result in result: # Might raise.
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/profiles/googlefonts.py", line 4741, in com_google_fonts_check_gf_axisregistry_valid_tags
for axis in family_metadata.axes:
Result: ERROR
>> Check: com.google.fonts/check/metadata/consistent_axis_enumeration
Desc: Validate VF axes match the ones declared on METADATA.pb.
Files: WynyardMono[wght].ttf
* ERROR: Failed with AttributeError: 'NoneType' object has no attribute 'axes'
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/checkrunner.py", line 366, in _exec_check
for sub_result in result: # Might raise.
File "/opt/hostedtoolcache/Python/3.8.6/x64/lib/python3.8/site-packages/fontbakery/profiles/googlefonts.py", line 4828, in com_google_fonts_check_metadata_consistent_axis_enumeration
md_axes = set(axis.tag for axis in family_metadata.axes)
Result: ERROR
โ
let me know if you'd like me to open a separate issue on fontbakery and can do so.
these aren't as urgent for me, happy to wait till the next un-emergency release if it's a pain to fix
I think these are also likely easy fixes as well. Maybe I was too eager to release quickly and missed the opportunity to address any other issues like this one as well :-P
As a matter of common practice, yes, please get used to posting issues like this on the fontbakery issue tracker. I try to always monitor them and fix the problems asap
I will fix these problems and I will run fontbakery on a local copy of your JetBrainsMono git repo so that we don't miss other issues as well (actually I should have done this before the 0.7.33 release, but I did not consider doing so... :-P)
Most helpful comment
The problem is fixed and I made an emergency FontBakery v0.7.33 release now including the fix. Please only close this issue after you ensure your setup is working nicely again.
https://pypi.org/project/fontbakery/0.7.33/