toolshed/organising
7
1
Fork 0
Code Issues 100 Pull Requests Releases Activity

Improving the recipe release process #663

New Issue
Closed
opened 2025-01-01 15:43:39 +00:00 by decentral1se · 11 comments
decentral1se commented 2025-01-01 15:43:39 +00:00
Owner
Copy Link

/cc @3wordchant @iexos

link to thread

Less magic (and things breaking) in abra recipe release and a clear separation in the pushing of changes to a remote.

We should also take this opportunity to improve clean up in the release process, when things go wrong? I think it might make sense to rollback the commit if something breaks. A brainstorm on testing scenarios for integration testing is welcome!

Thoughts?

/cc @3wordchant @iexos > [link to thread](https://matrix.to/#/!DfXPgKLoYCvjHithgS:autonomic.zone/$UTQaZRyUA_VdWc9TipdPsT3VR_JzXqtkD-z6Rq-vdTI?via=autonomic.zone&via=matrix.org&via=cyberia.club) Less magic (and things breaking) in `abra recipe release` and a clear separation in the pushing of changes to a remote. We should also take this opportunity to improve clean up in the release process, when things go wrong? I think it might make sense to rollback the commit if something breaks. A brainstorm on testing scenarios for integration testing is welcome! Thoughts?
decentral1se added the
enhancement
abra
 labels 2025-01-01 15:43:39 +00:00
iexos commented 2025-01-01 16:16:31 +00:00
Member
Copy Link

For me it makes total sense to seperate recipe release and recipe publish. Though on the naming I am not sure, I associate "making a release" with publishing as well.

Is there any reason why recipe sync, which does nothing but change the version label iirc, should be seperated from creating the commit (i.e. release)? Does recipe release without publish anything more than creating that commit (and i think asking for release notes)?

My proposal right now:

  • keep recipe upgrade as it is
  • have recipe sync change the label like before but also create the commit
    • here abra should also ask for release notes
  • have recipe release check if push and tagging will work, then create the tag and push it
    • this could also be named recipe publish instead, it might make the transition clearer. Also sync could then be named release instead, though that might reintroduce confusion
For me it makes total sense to seperate `recipe release` and `recipe publish`. Though on the naming I am not sure, I associate "making a release" with publishing as well. Is there any reason why `recipe sync`, which does nothing but change the version label iirc, should be seperated from creating the commit (i.e. release)? Does `recipe release` without publish anything more than creating that commit (and i think asking for release notes)? My proposal right now: * keep `recipe upgrade` as it is * have `recipe sync` change the label like before but also create the commit * here abra should also ask for release notes * have `recipe release` check if push and tagging will work, then create the tag and push it * this could also be named `recipe publish` instead, it might make the transition clearer. Also `sync` could then be named `release` instead, though that might reintroduce confusion
👍 1
3wordchant commented 2025-01-03 02:27:35 +00:00
Owner
Copy Link

Does recipe release without publish anything more than creating that commit (and i think asking for release notes)?

It creates the git tag.

have recipe release check if push and tagging will work, then create the tag and push it

I'm torn about this. Being able to test abra app upgrade without pushing is useful. But, I've seen multiple situations where people release an upgrade but don't push the tag, which is very nonideal. Happy to defer to whoever has a clear vision here.

> Does `recipe release` without publish anything more than creating that commit (and i think asking for release notes)? It creates the git tag. > have `recipe release` check if push and tagging will work, then create the tag and push it I'm torn about this. Being able to test `abra app upgrade` without pushing is useful. But, I've seen multiple situations where people release an upgrade but don't push the tag, which is very nonideal. Happy to defer to whoever has a clear vision here.
iexos commented 2025-01-04 14:02:01 +00:00
Member
Copy Link

But, I've seen multiple situations where people release an upgrade but don't push the tag, which is very nonideal. Happy to defer to whoever has a clear vision here.

This is actually the reason I brought it up. How does this actually happen? I image just using git push without --tags?

Releases should be

  1. properly tested before publishing
  2. properly published in the catalogue

Each of these fails sometimes.

I feel we need a common workflow that enables both and is supported and pushed for by abra.

I try to break it down to what is happening right now, maybe we find some clarity as to what would be the ideal release flow:

  • changes made to the recipe (abra recipe upgrade and/or manual)
    • pushing image tags and/or other recipe changes
  • test the changes (manual, there is also CI though I don't really understand what it does)
    • needs to happen somewhere in between here and publishing in the catalogue
    • if it fails, start from the beginning
  • update the recipe version (abra recipe sync)
  • create the release notes (abra recipe release)
  • create the commit (abra recipe release)
    • if it fails e.g. due to missing git user setting, re-run abra recipe release
  • create the tag (abra recipe release)
  • push the commit and the tag (abra recipe release --publish)
    • if abra recipe release already done or fails in some way, need to do git push --tags
    • if it fails due to conflict, probably need to rebase changes. Here a full understanding of the process is helpful

I am not sure if all of this is correct, please add anything that is missing or wrong!

So here is another try at a new flow:

  1. abra recipe upgrade:
    1. check for unstaged changes (pure upgrade commit)
    2. ask for image labels to push as usual
    3. create commit
      1. if it fails, revert changes
  2. manual testing
  3. abra recipe release, which does all of this:
    1. check for unstaged changes (pure release commit)
    2. check if any config file versions need pushing (and maybe other checks? abra recipe check? "did you actually test this? ;)")
    3. check if up-to-date with upstream (avoid conflicts)
    4. ask for semver type of release
    5. check that recipe part of the version does not exist yet (avoid conflicts, see also #638)
    6. ask for release notes and pick up releases/next
    7. sync the recipe version label
    8. create the commit
      1. if this fails, revert changes to be able to do the release again
    9. create the tag
    10. push commit and tag
      1. if pushing fails due to connectivity, just note to do abra recipe release again later. It should recognize release commits
      2. if pushing fails due to conflict, ask if tag and commit should be removed to be able to pull/rebase upstream changes

Of course this needs thorough testing so we actually trust this. The release process is complex. I feel the more we automate it, the easier it will be for maintainers to not mess up. I think its worth the additional complexity in abra, though easy for me to say as I don't maintain it 😅

> But, I've seen multiple situations where people release an upgrade but don't push the tag, which is very nonideal. Happy to defer to whoever has a clear vision here. This is actually the reason I brought it up. How does this actually happen? I image just using `git push` without `--tags`? Releases should be 1. properly tested before publishing 2. properly published in the catalogue Each of these fails sometimes. I feel we need a common workflow that enables both and is supported and pushed for by `abra`. I try to break it down to what is happening right now, maybe we find some clarity as to what would be the ideal release flow: - changes made to the recipe (`abra recipe upgrade` and/or manual) - pushing image tags and/or other recipe changes - test the changes (manual, there is also CI though I don't really understand what it does) - needs to happen somewhere in between here and publishing in the catalogue - if it fails, start from the beginning - update the recipe version (`abra recipe sync`) - create the release notes (`abra recipe release`) - create the commit (`abra recipe release`) - if it fails e.g. due to missing git user setting, re-run `abra recipe release` - create the tag (`abra recipe release`) - push the commit and the tag (`abra recipe release --publish`) - if `abra recipe release` already done or fails in some way, need to do `git push --tags` - if it fails due to conflict, probably need to rebase changes. Here a full understanding of the process is helpful I am not sure if all of this is correct, please add anything that is missing or wrong! So here is another try at a new flow: 1. `abra recipe upgrade`: 1. check for unstaged changes (pure upgrade commit) 2. ask for image labels to push as usual 3. create commit 1. if it fails, revert changes 2. manual testing 3. `abra recipe release`, which does all of this: 1. check for unstaged changes (pure release commit) 2. check if any config file versions need pushing (and maybe other checks? `abra recipe check`? "did you actually test this? ;)") 3. check if up-to-date with upstream (avoid conflicts) 4. ask for semver type of release 5. check that recipe part of the version does not exist yet (avoid conflicts, see also #638) 6. ask for release notes and pick up `releases/next` 7. sync the recipe version label 8. create the commit 1. if this fails, revert changes to be able to do the release again 9. create the tag 10. push commit and tag 1. if pushing fails due to connectivity, just note to do `abra recipe release` again later. It should recognize release commits 2. if pushing fails due to conflict, ask if tag and commit should be removed to be able to pull/rebase upstream changes Of course this needs thorough testing so we actually trust this. The release process is complex. I feel the more we automate it, the easier it will be for maintainers to not mess up. I think its worth the additional complexity in `abra`, though easy for me to say as I don't maintain it 😅
decentral1se commented 2025-01-04 14:28:16 +00:00
Author
Owner
Copy Link

amazing @iexos tysm for writing this all out

properly tested before publishing

join me in this rabbit hole #514

And related, there is also the WIP maintainers proposal:

https://pad.autonomic.zone/42Ier8ZgQ-CUgBsFKUmdpQ?view

We're due a collective brain dump here, let's try to get ourselves into the next kite flying hour?

amazing @iexos tysm for writing this all out > properly tested before publishing join me in this rabbit hole https://git.coopcloud.tech/toolshed/organising/issues/514 And related, there is also the WIP maintainers proposal: > https://pad.autonomic.zone/42Ier8ZgQ-CUgBsFKUmdpQ?view We're due a collective brain dump here, let's try to get ourselves into the next kite flying hour?
decentral1se changed title from Move `--publish/-p` to a new `abra recipe publish` to Improving the recipe release process 2025-01-05 12:14:01 +00:00
simon commented 2025-02-15 12:44:57 +00:00
Member
Copy Link

Hey, just jumping into the discussion here.

What do you think of delegating the actual release tagging to Drone?

I think all the recipe development tasks we do shouldn't depend on actual tags, e.g. checking if an upgrade works or else. I'd love to be able to work on branches, have pull requests with automated checks, quality gates and optionally reviews. A release/new tag should therefore only be created when merged into main.
So either I'd like to manually start a drone job from the UI or it might be able to check for a new version in the compose.yml label for the app?

And with that, I'd love to be able to have feature-branch deployments. So when specifing a version in the .env-file, I could add the branch name to always deploy the latest version from the branch?
Might also allow to ommit the -C flag for alle those commands in that situation?

Lots of rambling around here, but I'd love to talk about this in a kite-flying session!

PS: I previously worked in a team where we've made it so fast and fluent to deploy stuff via CI/CD, that we all preferred to use those tools over manual deployments or release processes. Really loved that actually

Hey, just jumping into the discussion here. What do you think of delegating the actual release tagging to Drone? I think all the recipe development tasks we do shouldn't depend on actual tags, e.g. checking if an upgrade works or else. I'd love to be able to work on branches, have pull requests with automated checks, quality gates and optionally reviews. A release/new tag should therefore only be created when merged into main. So either I'd like to manually start a drone job from the UI or it might be able to check for a new version in the compose.yml label for the app? And with that, I'd love to be able to have feature-branch deployments. So when specifing a version in the .env-file, I could add the branch name to always deploy the latest version from the branch? Might also allow to ommit the -C flag for alle those commands in that situation? Lots of rambling around here, but I'd love to talk about this in a kite-flying session! PS: I previously worked in a team where we've made it so fast and fluent to deploy stuff via CI/CD, that we all preferred to use those tools over manual deployments or release processes. Really loved that actually
❤️ 1
decentral1se commented 2025-02-17 09:49:41 +00:00
Author
Owner
Copy Link

@simon nice! check #514 I think that'd be going more in that direction. We need some sort of semi-automated process with human review in the middle or towards the end somehow.

@simon nice! check https://git.coopcloud.tech/toolshed/organising/issues/514 I think that'd be going more in that direction. We need some sort of semi-automated process with human review in the middle or towards the end somehow.
👍 1
decentral1se added this to the Recipe release stability project 2025-04-20 06:06:12 +00:00
decentral1se commented 2025-08-19 16:56:34 +00:00
Author
Owner
Copy Link

FYI I'm leaning towards the "new flow" in #663 (comment) from @iexos 👏

FYI I'm leaning towards the "new flow" in https://git.coopcloud.tech/toolshed/organising/issues/663#issuecomment-22329 from @iexos 👏
decentral1se moved this to In Progress in Recipe release stability on 2025-08-24 14:01:52 +00:00
decentral1se commented 2025-08-24 14:03:32 +00:00
Author
Owner
Copy Link

two small improvements:

  • toolshed/abra#576: if abra recipe release -p fails it will now soft reset to remove the commit and delete the tag, allowing you to run the command again (after you unbork your SSH setup) to complete the publishing (without a manual git work-around)
  • toolshed/abra#611: abra recipe sync will show all the proposed changes as a visual aid to decide which kind of bump it should be
two small improvements: * https://git.coopcloud.tech/toolshed/abra/issues/576: if `abra recipe release -p` fails it will now soft reset to remove the commit and delete the tag, allowing you to run the command again (after you unbork your SSH setup) to complete the publishing (without a manual git work-around) * https://git.coopcloud.tech/toolshed/abra/pulls/611: `abra recipe sync` will show all the proposed changes as a visual aid to decide which kind of bump it should be
iexos commented 2025-09-30 17:12:15 +00:00
Member
Copy Link

I'm torn about this. Being able to test abra app upgrade without pushing is useful.

@3wordchant I don't see why this is would be needed, isn't it the same as using abra app deploy --force --chaos with the unreleased version? I am working on breaking down my proposal and would like to make --publish the default and remove the flag.

> I'm torn about this. Being able to test `abra app upgrade` without pushing is useful. @3wordchant I don't see why this is would be needed, isn't it the same as using `abra app deploy --force --chaos` with the unreleased version? I am working on breaking down my proposal and would like to make `--publish` the default and remove the flag.
iexos commented 2025-10-01 11:02:13 +00:00
Member
Copy Link

Alright, I bombarded the abra issue tracker with some stuff I mentioned above 😅
toolshed/abra#682 toolshed/abra#683 toolshed/abra#684 toolshed/abra#685

These are all local changes to abra, not touching the subject of CI/deploy testing which might actually be more important (but also more involved).

Alright, I bombarded the abra issue tracker with some stuff I mentioned above 😅 https://git.coopcloud.tech/toolshed/abra/issues/682 https://git.coopcloud.tech/toolshed/abra/issues/683 https://git.coopcloud.tech/toolshed/abra/issues/684 https://git.coopcloud.tech/toolshed/abra/issues/685 These are all local changes to abra, not touching the subject of CI/deploy testing which might actually be more important (but also more involved).
🚀 1
decentral1se commented 2025-10-01 13:14:50 +00:00
Author
Owner
Copy Link

Thanks @iexos, let's run with those tickets and close this galaxy brain one. Thanks all!

Thanks @iexos, let's run with those tickets and close this galaxy brain one. Thanks all!
decentral1se moved this to Done in Recipe release stability on 2025-10-01 13:15:00 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abra
Everything to do with abra
abra-gandi
Abra Gandi plugin
awaiting-feedback
Ping/pong on comms
backups
bug
Something is not working
build
Go build related issues
ci/cd
Getting the robots into the mix
community organising
Opening this thing up
contributing
Contributors stuff
coopcloud.tech
Our main website
democracy
Democratic decision making
design
Design thinking required
documentation
Let's write things together
duplicate
This issue or pull request already exists
enhancement
New feature
finance
Money things
funding
Anything related to grant funding
good first issue
Easy start with development
help wanted
Need some help
installer
Installation related issues
kadabra
performance
Performance related
proposal
Large change which requires feedback & decisin making
question
More information is needed
recipes.coopcloud.tech
Our recipes catalogue
security
Securing our shit
test
Unit or integration test suite
wontfix
This won't be fixed
No Label
abra
enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project Recipe release stability
Assignees
Clear assignees
3wordchant aadil abra-bot ammaratef45 Apfelwurm carla cas coopcloud cyrnel decentral1se fauno iexos jade jmakdah2 joe-irving kawaiipunk knoflook kolaente lambdabundesverband linnealovespie moritz notplants p4u1 pharaohgraphy renovate-bot ripclap simon sixsmith trav val yksflip
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/organising#663
No description provided.
Delete Branch "%!s()"

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?