So, thinking about it twice, we might actually use plone/meta to define the workflows and configuration files that are needed, and eventually once that is mature enough, we can start promoting stable workflows to general ones given that one can still set some variables to disable certain workflows (like the black example).
If this is about GitHub workflows only, we will still need plone/meta to configure all but what's not on the .github/workflows folder, i.e. tox.ini, pyproject.toml etc.
Sorry if I am late to the party, but it seems to me that this tool requires a docker to run.
It seems to me this is like nuking a mosquito.
In addition it is yet another tool we are developing while there are already available mainstream Python tools like pre-commit that have already tons of plugins available for everything (rst, ansible yml files, ...).
I would ask everybody to reconsider the widespread adoption of this tool.
I am not a big fan of pre-commit hooks. But the pre-commit tool makes this optional, which helps for adoption. It looks very mature now, and I would love to explore it further.
I'm not a huge fan of pre-commit, but I can reconsider my opinion given enough reasoning
This tooling has to serve a few purposes:
run in CI: GitHub at least, but maybe jenkins as well?
run locally: while developing
be easy to set up and use: otherwise only a few will use it and that would defeat its all purpose
My main complain about pre-commit is that you have yet another set of configuration files and version pins to maintain if it's enough trouble to get CI stable, try the same with 2, 3, 4 tools to run almost-the-same-thing-but-not-exactly (tox, GitHub actions, pre-commit, jenkins, your local virtual environment, whatever is configured on buildout.coredev ...).
If we can get a configuration/setup that allows to maintain a single source of truth to get a repeatable and stable CI/linting I'm all for it.
Interestingly enough, on Alpine Sprint they want to work on pre-commit, so maybe there is indeed a way to combine GitHub Actions, tox (current setup of meta repositories) together with pre-commit
Given I am actually using since quite some years pre-commit, I can just tell you that with very small effort you get to the point (i.e. clean code) and the maintenance burden is almost zero.
To update your pins just run pre-commit autoupdate and that's almost it.
Sometimes you have to run pre-commit run --all and in many cases that automatically fixes what's wrong.
They will never interfere with your env because they are installed in they own virtuaenv.
For me it is much more a blocker to convince anybody to install docker to fix some formality on a PR.
Using Docker was a good way not to install everything locally and end up with distinct versions between your CI and local env. Nothing is blocking us from integrating this to pre-commit or other tools.
A few months ago @jensens mentioned pipx could be a valid alternative to Docker, but I still have some minor concerns about its usage.
I would love to discuss it during Alpine City Sprint
I have good and bad news about these new features from GitHub
: defining the workflows globally does work you can also specify for which projects to run the workflows you can define global variables variables have to be a single value, not a list of values
This last point is a bit of cumbersome, as we can not say, define a generic tests.yml workflow, and on a per repository basis define the matrix of OS/plone/python versions to run the tests with
if it's enough trouble to get CI stable, try the same with 2, 3, 4 tools to run almost-the-same-thing-but-not-exactly (
: defining the workflows globally does work
variables have to be a single value, not a list of values
