Right, we can bend it to our needs sure
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
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.
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.
Optionally a repo could use https://pre-commit.ci to run the checks on all PRs.
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
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.
That's why I started the GitHub - plone/meta: Meta issues concerning many/all of the plone repositories. fork from GitHub - zopefoundation/meta: Meta issues concerning many/all of the zopefoundation repositories. as the Zope community have been using that for quite some time and they are happy about 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
I do not want to start a big discussion trying to convince anybody.
I was triggered in to this by this PR Add lint and format tox environments. by mauritsvanrees · Pull Request #81 · collective/collective.recipe.backup · GitHub (see the comment trail).
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.
You are never late.
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 also use
pipx but for other stuff, e.g. having globally available commands (e.g. I have a pipx installed
Yeah, it will be great