Protect main branch of recipes #777

New Issue

2026-02-16T11:24:00Z

benjaminlyng commented

2026-02-16 11:24:00 +00:00

Upgrading recipes requires pushing new commits and tags directly to the main branch of the repository. This is risky and it requires enormous trust in maintainers. The risk is somewhat reduced by automating the procedure with abra, but it would be even better to protect the main branches of recipes. The way I imagine upgrades with protected main-branches is to push new commits to feature-branches, require maintainer approvals before merges and then handle creation of tags in pipelines.

Requirements:

Option to deploy feature-branch of recipe to a server to test before new release. (I think that works already with the --chaos flag?)
CI job to generate tag based on the logic in abra today.
Some method to trigger tag creation as you probably won't need a new tag on each branch merged to main. Either a manually triggered pipeline or automatic by using Conventional Commits or something like that.
Importing the CI job from a template into each recipe.

This could also potentially make the renovate bot extremely powerful, as new upgrades would just require merging it's MRs (after testing the feature-branch of course).

I realize this requires a change to every recipe repo, but it should be possible to change one at a time by just including a pipeline template. It would change the workflow for every maintainer using coopcloud so it has to be discussed thoroughly before implementing!

Upgrading recipes requires pushing new commits and tags directly to the main branch of the repository. This is risky and it requires enormous trust in maintainers. The risk is somewhat reduced by automating the procedure with `abra`, but it would be even better to protect the main branches of recipes. The way I imagine upgrades with protected main-branches is to push new commits to feature-branches, require maintainer approvals before merges and then handle creation of tags in pipelines. Requirements: * Option to deploy feature-branch of recipe to a server to test before new release. (I think that works already with the `--chaos` flag?) * CI job to generate tag based on the logic in `abra` today. * Some method to trigger tag creation as you probably won't need a new tag on each branch merged to main. Either a manually triggered pipeline or automatic by using Conventional Commits or something like that. * Importing the CI job from a template into each recipe. This could also potentially make the renovate bot extremely powerful, as new upgrades would just require merging it's MRs (after testing the feature-branch of course). I realize this requires a change to every recipe repo, but it should be possible to change one at a time by just including a pipeline template. It would change the workflow for every maintainer using coopcloud so it has to be discussed thoroughly before implementing!

decentral1se commented

2026-02-16 13:42:46 +00:00

hey @benjaminlyng, thanks for opening this and sharing your thoughts.

You're on the right track, and your initiative is very welcome. We recently wrote https://docs.coopcloud.tech/maintainers/maintain/ together after some of us met at CCC in germany. This was a follow-up of https://docs.coopcloud.tech/federation/resolutions/passed/025/ which was voted on.

There has been a serious amount of collective discussion on this topic in the last few months.

The TLDR; is to reduce the chaos of upgrades through encouraging more maintainers to get involved on specific recipes they maintain. You'll see in https://docs.coopcloud.tech/maintainers/maintain/#repository-permissions that the main branch does get protected. This will reduce the worst of the "push to main" praxis we've had for several years which is now becoming untenable due to increasing participation (a great problem to have).

I would recommend you consider joining the federation and/or becoming a recipe maintainer and getting involved via that route. If you want to discuss specific concrete things that maintainers can implement, I'd ask first in the matrix channels and then if it sees traction, raise a broader issue on https://git.coopcloud.tech/toolshed/organising/issues. This could then be integrated into the MAINTENANCE.md agreements that each maintainer agrees to honour.

This issue isn't specifically about abra and concerns broader issues, so I will close it here. If you're looking for more discussion on how abra recipe release should improve, that'd be over here: toolshed/organising#663.

I hoep that is clear, thanks!

hey @benjaminlyng, thanks for opening this and sharing your thoughts. You're on the right track, and your initiative is very welcome. We recently wrote https://docs.coopcloud.tech/maintainers/maintain/ together after some of us met at CCC in germany. This was a follow-up of https://docs.coopcloud.tech/federation/resolutions/passed/025/ which was voted on. There has been a serious amount of collective discussion on this topic in the last few months. The TLDR; is to reduce the chaos of upgrades through encouraging more maintainers to get involved on specific recipes they maintain. You'll see in https://docs.coopcloud.tech/maintainers/maintain/#repository-permissions that the main branch does get protected. This will reduce the worst of the "push to main" praxis we've had for several years which is now becoming untenable due to increasing participation (a great problem to have). I would recommend you consider joining the federation and/or becoming a recipe maintainer and getting involved via that route. If you want to discuss specific concrete things that maintainers can implement, I'd ask first in the matrix channels and then if it sees traction, raise a broader issue on https://git.coopcloud.tech/toolshed/organising/issues. This could then be integrated into the `MAINTENANCE.md` agreements that each maintainer agrees to honour. This issue isn't specifically about `abra` and concerns broader issues, so I will close it here. If you're looking for more discussion on how `abra recipe release` should improve, that'd be over here: https://git.coopcloud.tech/toolshed/organising/issues/663. I hoep that is clear, thanks!

decentral1se closed this issue

2026-02-16 13:42:46 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#777