chore: publish 5.1.0+v3.6.11 release #98
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/traefik#98
Reference in New Issue
Block a user
No description provided.
Delete Branch "cve_patch"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
abra.sh@decentral1se I wonder if it makes sense to merge it with the coopcloud label update. Now we can't just run abra recipe release anymore right?
I wonder a bit about the release process. I used abra recipe release, because we need the tag to already deploy the app in our systems. Especially if it fixes CVEs this must happen fast and we can't wait for the PR to be merged.
Now it's not a problem because the tag is already pushed, even the PR is not merged. But this somehow seems inconsistent.
Ohhhhhh, the tag was already pushed before the pull request was reviewed / merged 😆 Right, we need to think about this 🤔
I like the full diff with labels and making the recipe maintainership visible and collective. But indeed, it just automatically makes the release before the PR is reviewed... @iexos do you have some wisdom to share on this? It would seem like the new
abra recipe releaseworkflow helped a lot of people but now we have a new problem ☺️I would still personally like some sort of process which allows for "push tags at random to the repo" and "bring blessed tags over to the catalogue which have been agreed upon". I'm not sure this is the time to bring that in 🤔
In the old release way I also liked that it's possible to create a patch release in between two already published versions by just pushing it to another branch and tagging it. But this also circumvents the PR process. But it's the only way to patch a recipe without bumping the image version, if a newer one is already released.
I think we should only allow recipe maintainers to push tags. Otherwise our whole maintenance system is flawed. If you really need to deploy a quick fix you can always deploy a commit hash instead of a tag. In the case of this recipe, I really think wee need at least two more maintainers, since we are currently oy 2 really and the then burden would shared more. Also I wonder how you get noticed on cve, as this something we should propay setup for all recipes.
We use the alert system of https://vulners.com to get informed about new CVEs. We from LIT would like to join the maintainers of this recipe.
An intermediate version patch is not a quick fix deployed on some instance. Sometimes we publish older versions as stable for the kollicloud, because new images contain bugs or would break some integrations. At the moment we couldn't publish a hash as stable release.
For us it is an advantage of git tags, that they can reference different branches and don't rely on the main branch.
Getting CVEs & renovate sorted: toolshed/coop-cloud-apps#23
I've removed this repo from the co-operators team write access (I thought it was gone already 🙃) and added you @moritz to https://git.coopcloud.tech/org/coop-cloud/teams/traefik-maintainers following our current proposed setup: https://docs.coopcloud.tech/maintainers/maintain/#maintainers-team. The ad-hoc nature of how https://git.coopcloud.tech/org/toolshed/teams came to be might be finally working against us here 😅 Proposals welcome 🙈
As for the pull request /
abra recipe releaseworkflow, I'm not sure. Does anyone have a proposal? It would seem that the simplest option is to not include the label changes for the review as @p4u1 said and letabra recipe releasedo this for you when you make the release it.I hope you all have patience for more, we're getting there 🫡
Can someone open an issue regarding the problem with the new release flow? I don't fully grasp what you would like to achieve. I optimized the release flow for single maintainer releasing, we obviously need something else for PR-based releases.
toolshed/abra#806