Closed gotcha closed 11 months ago
GitHub has this concept of shared/organization level workflows, say to only allow contributors that have signed an agreement, or license validation, etc.
To set those up, you need to go to the organization, and select the actions panel.
There, if you scroll to the bottom, you have Required workflows
section.
In that section you can add as much workflows as you wish and either select that all repositories must run that workflow, or only the ones you select.
On plone/meta's README it is mentioned as well 😄
It's a bit unfortunate that you can not "see" it from the code itself, but it has the huge upside that one can then update a single file and all repositories enabled follow suit.
For linting, we use pre-commit.ci, so yet again, something not configured on the repository itself but rather on the integration of pre-commit with GitHub.
Fortunately, all tox
environments are defined per repository, so you can still do the same as CI would do:
tox -e lint
: to mimic pre-commit.ci
tox -e test
: to mimic GHA
We have two other tox
environments that we don't run by default:
tox -e format
: a subset of lint
environment
tox -e dependencies
: to check that all dependencies are defined correctly (uses z3c.dependencychecker
under the hood) and eventually we will integrate pipforester
Is that enough? 🤔
Well, being an old pythonista, I do really think that "explicit is better than implicit" so it is really unfortunate that you cannot see the stuff on the repo itself.
Now, if I go that actions panel I do not see which repos have that workflow setup.
Is that a permission problem ? Or another place where Python wisdom is not applied ?
I just read https://docs.github.com/en/actions/using-workflows/reusing-workflows.
IIUC, it would enable us to share workflows inside the organization AND be explicit which workflows are setup in the repos.
Next to the 13 repositories
there are three dots, clicking on that allows you to configure that workflow 👍🏾
And indeed, I was at odds with it as well, I very much like to be able to browse to the .github/workflows
folder and inspect what's going on there.
At the same time though, thinking of updating all +100 plone repositories (once all plone core repositories are configured) because we add coverage reports, or thinks like that, oh my, that's something I don't look forward to.
I will read the reusing-workflows document later, thanks for sharing! ✨ 🍀
@gforcada I had seen those three dots and clicked 🙄 and saw nothing. Cause you need to make even more clicks in a not very friendly UX before you can read which repos are bound.
Is that settings page accessible to any Plone contributor ? That seems frightening.
My understanding of the reusing workflows document makes me think that we can implement the ability to add coverage in a single workflow file whenever you want to add it to all repos where you want to run it.
I would keep the signed contributor agreement in a seperate workflow as this could be considered as compulsory. IOW not removable by pushing to the repo.
The contributor agreement was an example, same like coverage, we will see how we implement it at the end.
Maybe the unfriendliness of the UI is due to its beta state, I guess? 🤔
And no, hopefully not every contributor in the plone organization has access to that page... ❗
Since then, we moved to install the GitHub actions locally, so we don't require any global workflow.
If you have more questions regarding the actions and plone/meta
in general, please create new issues on https://github.com/plone/meta/issues 😄
I am looking for a
.github
directory which is not there. Actions UI mentionsplone/meta/shared-workflows/tests.yml
. How/where is that setup ?@gforcada @mauritsvanrees