I maintain `repomatic`, a Python CLI + reusable workflows. It bakes most of the practices from this post into a drop-in setup for Python projects (uv-based, but works for others too). The goal is to make the secure default the easy default for maintainers who just want to ship packages. Also addresses a lot of GitHub Actions own shortcomings.
But thanks to the article I added a new check for the fork PR workflow approval policy.
For the moment I consider that only one agent can be active. If multiple are detected, I raise an error. That is intentional to gather more context and feedback from users. I will change this behavior as soon as someone report me a use-case.
Maybe ERPs are the ultimate test of an agile culture. Sounds weird right? But bear with me.
Most ERP projects fail. They end up over-budget and delivered really late.
Why? They are sold like custom implementations, promising the stakeholders they’ll be adapted to their specific needs. It's rarely the case. The reality requires the whole business to change: its processes, its workflows, its traditions.
Therefore, only companies flexible enough can survive such deep transformations. Companies that are agile.
Nothing protect you from a `yay -S foo` install and its dependencies. So this is not a guarantee or enforcement of a minimum release-age.
Actually writing this reply I went ahead and pointed that out in an issue at: https://github.com/Jguer/yay/issues/2883