Fontbakery: Post issues for users

[davelab6]

When users first use Font Bakery to check their project, they may want to run Font Bakery's command line tool against their repo, in the same way that the dashboard can ingest a repo.

The most simple thing I can think of is that FB should accept URLs along with directory paths or a set of file paths. However, perhaps it is better to have a new 'shorthand' command, like

fontbakery check-googlefonts-github [email protected]:username/project

Following on from this, I can see that users of Font Bakery may wish to 'spray' their Github Issue tracker with one issue per failed check, like Eli did for himself just now:

Perhaps a command like one of these,

fontbakery check-googlefonts-github [email protected]:username/project --post-issues
fontbakery check-googlefonts-github-and-post [email protected]:username/project

would mean that, after the complete check results are printed, for each fail it asks you y/[n] style if you want to auto-post an issue.

• [ ] And in the case you already ran FB and want to 'firehose spray' the issue tracker with everything, there should be a mode to to 'auto post' all, like :

  fontbakery check-googlefonts-github [email protected]:username/project --post-issues --yes
  fontbakery check-googlefonts-github [email protected]:username/project --post-issues --hard
  fontbakery check-googlefonts-github-and-post [email protected]:username/project --auto

etc

[madig]

What about repeated runs as you design/engineer around or in a CI context? The script could instead post a single issue with a date/commit ID/branch attached and update that issue on subsequent runs.

[davelab6]

Sure. I'm open to anything, the point is that it's wasted time posting
issues manually by copy and paste :)

[felipesanches]

I've manually prototyped this idea by copying and pasting FAILs and WARNs into the Crispy-VF repo:
https://github.com/agyeiarcher/Crispy-VF/pull/34

If the formatting used in this experiment turns out to be good, I can transform that into proper python code to automate the task. Let's see what @agyeiarcher thinks about this first sketch of the feature ;-)

[laerm0]

Up next: Travis filing issues for you?

[felipesanches]

YES!

[felipesanches]

And more! Maybe even updating issue description whenever the check rationale is updated. Not sure if it is worth it, but I considered doing so. I'll have to detect whether the issue was already posted in order to avoid posting duplicates, so it is a very minor step from actually performing the update of rationale text if actually needed...

[felipesanches]

This kind of feature will likely increase the visibility of fontabakery. So, I expect this will also end up bringing more user feedback for improving the tool.

[madig]

You could try to implement this as a GitHub Action: https://github.com/features/actions. I think it's quite flexible. With some build system integration, it could also be implemented as a traditional CI check that just blocks merging instead of filing issues.

[m4rc1e]

gftools qa already posts qa reports back to repos automatically. If it's checking a pr, it will post it as an issue to the pr (how the ci currently works on google/fonts). If it's a dir containing fonts binaries, it opens a new issue.

[felipesanches]

I have to take a look at it, @m4rc1e

Instead of posting the full check results summary in a single issue/pr, my experimental workflow involves posting individual issues per FAIL or WARN so that each can be discussed separately on their respective issue threads in the upstream font project repo.

[m4rc1e]

Nice. I look forward to seeing what you come up with. It may be a good idea to add this functionality once we've fixed most of the checks which produce false positives.

We should start planning how we should share these functions across our tools/libs. I've probably written a function to download families from Google Fonts three times. It would be nice to have such code consolidated into a single lib or added to an existing one. This may also be a terrible idea but imo it's worth discussing.