Improving the recipe release process #663

Open
opened 2025-01-01 15:43:39 +00:00 by decentral1se · 6 comments
Owner

/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

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
Owner

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.

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 😅
Author
Owner

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
Member

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
Author
Owner

@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.
decentral1se added this to the Recipe release stability project 2025-04-20 06:06:12 +00:00
Sign in to join this conversation.
No description provided.