I was looking into the PR googlefonts/fontbakery#2662 of @eliheuer. It implements com.google.fonts/check/repo/vf_has_static_fonts and that uses as condition gfonts_repo_structure.
As a reference:
@condition
def gfonts_repo_structure(fonts):
""" The family at the given font path
follows the files and directory structure
typical of a font project hosted on
the Google Fonts repo on GitHub ? """
from fontbakery.utils import get_absolute_path
# FIXME: Improve this with more details
# about the expected structure.
abspath = get_absolute_path(fonts[0])
return abspath.split(os.path.sep)[-3] in ["ufl", "ofl", "apache"]
In the Font Bakery Dashboard, as of now, files packages are created exactly like they end up in google/fonts, but the files are not in an e.g. ofl/familyname directory. Hence, the PRed check, as well as com.google.fonts/check/family/has_license and com.google.fonts/check/repo/dirname_matches_nameid_1are skipped, despite of all of them should be running in the dashboard.
The solution would be to put files into their appropriate subdirectory and also teach all the workers to accept and if needed create sub-directories for all files in a FamilyJob. The GitHubOperations service also has to adapt.
Alternatively, the FamilyJob could also specify the sub-directory, but in the long run the former solution seems intuitively to be the most flexible.
This also prepares for VF-fonts, which seem to have a static subdirectory as well as for future "super-family" checks, where more than one family is checked, however, the super-family workflow is entirely undefined yet.
I was looking into the PR googlefonts/fontbakery#2662 of @eliheuer. It implements
com.google.fonts/check/repo/vf_has_static_fontsand that uses as conditiongfonts_repo_structure.As a reference:
In the Font Bakery Dashboard, as of now, files packages are created exactly like they end up in google/fonts, but the files are not in an e.g.
ofl/familynamedirectory. Hence, the PRed check, as well ascom.google.fonts/check/family/has_licenseandcom.google.fonts/check/repo/dirname_matches_nameid_1are skipped, despite of all of them should be running in the dashboard.The solution would be to put files into their appropriate subdirectory and also teach all the workers to accept and if needed create sub-directories for all files in a FamilyJob. The GitHubOperations service also has to adapt.
Alternatively, the FamilyJob could also specify the sub-directory, but in the long run the former solution seems intuitively to be the most flexible.
This also prepares for VF-fonts, which seem to have a
staticsubdirectory as well as for future "super-family" checks, where more than one family is checked, however, the super-family workflow is entirely undefined yet.