Update the GitHub Actions workflow for the Fluent linter

[timvandermeij]

The commit messages contain more details about the individual changes.

[Snuffleupagus]

Thanks for doing this clean-up, since consistency is always nice!

Looking at this a bit closer, I've got two questions about potential additional improvements:

• Would it be technically possible to "combine" the push and pull_request configurations, given what we do in another workflow, since we're currently duplicating the same configuration in both?
  

  pdf.js/.github/workflows/fluent_linter.yml

  Lines 3 to 16 in 238f3e7

  	push:
  	paths:
  	- 'l10n/en-US/**.ftl'
  	- '.github/fluent_linter_config.yml'
  	- '.github/workflows/fluent_linter.yml'
  	branches:
  	- master
  	pull_request:
  	paths:
  	- 'l10n/en-US/**.ftl'
  	- '.github/fluent_linter_config.yml'
  	- '.github/workflows/fluent_linter.yml'
  	branches:
  	- master

• Is it correct and/or meaningful to leave the following entry blank, or can the line be removed?
  

  pdf.js/.github/workflows/fluent_linter.yml

  Line 17 in 238f3e7

  workflow_dispatch:

[timvandermeij]

Would it be technically possible to "combine" the push and pull_request configurations, given what we do in another workflow, since we're currently duplicating the same configuration in both?

Sadly that's not possible in this case. In that workflow we trigger on the push and pull_request events using the default configuration, so only in that case can they be combined. If we need to override the default configuration, we have to do so per event type because the actual configuration can differ between the various event types. You can find more information at https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-activity-types-and-filters-with-multiple-events.

Is it correct and/or meaningful to leave the following entry blank, or can the line be removed?

This puzzled me as well for a bit, but I found out that this actually has a purpose. What is does is allow this workflow to be ran manually over at https://github.com/mozilla/pdf.js/actions/workflows/fluent_linter.yml (note the "This workflow has a workflow_dispatch event trigger" banner and the "Run workflow" button). This allows running the workflow on-demand outside of a pull request, which is mostly a convenience feature. The other workflows don't have it because conceptually they make less sense to run outside of the scope of a PR (although technically they could get this too).

[Snuffleupagus]

r=me, thank you!

[flodolo]

The linter is not tested with Python 3.12 🤔 I suggest to stick with 3.10 or 3.11

For me, with 3.12 tests fail to even install dependencies
https://github.com/mozilla-l10n/moz-fluent-linter/actions/runs/6694472871/job/18187850055?pr=14

[timvandermeij]

That particular build fails because it's fetching PyYAML 6.0 which doesn't have Python 3.12 wheels; see https://pypi.org/project/PyYAML/6.0/#files and see the PyYAML-6.0.tar.gz fetching part in those logs, which means the source package is fetched that then has to be built while the required build requirements are missing. However, in our build PyYAML 6.0.1 is fetched which fortunately does have Python 3.12 wheels and works just fine; see https://pypi.org/project/PyYAML/6.0.1/#files for the cp312 wheels and https://github.com/mozilla/pdf.js/actions/runs/6678649246/job/18149912927 for our workflow run where the "Install Fluent dependencies" picks up PyYAML-6.0.1-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

The difference between the builds is that we pip install the package directly so the version ranges from setup.py apply and therefore the latest PyYAML is fetched whereas the build you linked uses pip install -r .github/requirements.txt which pins PyYAML to a specific version for which no Python 3.12 wheels exists, thus building it from source.