Support generating tags using our anti-versioning approach #135

New Issue

femmefaytale · 2021-09-09T13:02:52Z

femmefaytale commented

2021-09-09 13:02:52 +00:00

coop-cloud/abra#93

femmefaytale added the

enhancement

label 2021-09-09 13:27:07 +00:00

decentral1se added this to the Command-line tool sustainability milestone 2021-09-09 14:24:40 +00:00

knoflook was assigned by decentral1se

2021-09-10 08:59:46 +00:00

decentral1se commented

2021-09-10 09:00:53 +00:00

Once we sort #120, this can be done. It'll require some rejigging of https://apps.coopcloud.tech but we can do it all in one go and just put it to bed once and for all.

Once we sort https://git.coopcloud.tech/coop-cloud/organising/issues/120, this can be done. It'll require some rejigging of https://apps.coopcloud.tech but we can do it all in one go and just put it to bed once and for all.

decentral1se added this to the Beta release (software) project 2021-09-10 09:01:25 +00:00

knoflook commented

2021-09-22 12:14:19 +00:00

Things to be done:

tag the current commit in a repo with a tag specified by user
support --major, --minor and --patch as flags for generating the new tag
generate the new tag based on repo tag history and differences in compose.yml
push the changes (only with a --push flag I guess?)
warn the user about a possible version conflict¹

¹ person A pulls wordpress version 2.4.1
person B pulls wordpress version 2.4.1
person A makes a minor change, pushes their work and the freshest wordpress version becomes 2.5.0
person B makes a patch on top of 2.4.1 and runs abra recipe release wordpress --patch but abra reads the tags from the remote repo and takes 2.5.0 as the newest version. So really it should be 2.4.2 but it's gonna get tagged as 2.5.1

the solution for that would be to not download tags from the remote before generating a new tag and only using the local tags.

Things to be done: - [x] tag the current commit in a repo with a tag specified by user - [ ] support `--major`, `--minor` and `--patch` as flags for generating the new tag - [ ] generate the new tag based on repo tag history and differences in compose.yml - [ ] push the changes (only with a --push flag I guess?) - [ ] warn the user about a possible version conflict¹ ¹ person A pulls wordpress version 2.4.1 person B pulls wordpress version 2.4.1 person A makes a minor change, pushes their work and the freshest wordpress version becomes 2.5.0 person B makes a patch on top of 2.4.1 and runs abra recipe release wordpress --patch but abra reads the tags from the remote repo and takes 2.5.0 as the newest version. So really it should be 2.4.2 but it's gonna get tagged as 2.5.1 the solution for that would be to not download tags from the remote before generating a new tag and only using the local tags.

decentral1se commented

2021-09-22 13:16:52 +00:00

zomg brain melter, just jotting this down, checked with @knoflook and this is maybe what the catalogue might looks like:

{"peertube": {
  ... 
  "versions": [
  {
    "1.0.2+2.3.4": {
      "app": { "tag": "2.3.4"},
      "db": { "tag": "1.2.0" },
      ...
    },
  },
  {...},
  ],
  ...
}

zomg brain melter, just jotting this down, checked with @knoflook and this is maybe what the catalogue might looks like: ```json {"peertube": { ... "versions": [ { "1.0.2+2.3.4": { "app": { "tag": "2.3.4"}, "db": { "tag": "1.2.0" }, ... }, }, {...}, ], ... } ```

decentral1se commented

2021-09-22 13:45:12 +00:00

I'm still trying to wrap my head around the "big picture" flow of this. Is it this?

the recipe catalogue (apps.coopcloud.tech) is the source of truth for "which versions are published"
you run abra recipe upgrade <recipe> and abra recipe sync <recipe> before running this new abra recipe tag <recipe> command. upgrade/sync will leave unchecked in changes into ~/.abra/apps/<recipe> (new image tags and new deploy labels which match those tags)
abra recipe tag <recipe> considers the local repository with unchecked in changes. It checks the app service tag and looks in the recipe catalogue versions list. If the app image tag is, say, 2.3.1 then we're looking for an a.b.c part of the x.y.z+a.b.c which matches? From there, we can do comparisons on the service tags and then ask the user - is this a minor/major/patch upgrade for the x.y.z part? (this is the un-automatable part, right?)
if there is no matching a.b.c part in the recipe catalogue then we can automate this release? We can follow the patch/minor/major of the upgrade and change the x.y.z part to match?

Unfinished thoughts...think we should deffo try to break stuff down into small parts and then just test the shit out of it...down to plan a meeting in to chat about this!

I'm still trying to wrap my head around the "big picture" flow of this. Is it this? - the recipe catalogue (apps.coopcloud.tech) is the source of truth for "which versions are published" - you run `abra recipe upgrade <recipe>` and `abra recipe sync <recipe>` before running this new `abra recipe tag <recipe>` command. `upgrade`/`sync` will leave unchecked in changes into `~/.abra/apps/<recipe>` (new image tags and new deploy labels which match those tags) - `abra recipe tag <recipe>` considers the local repository with unchecked in changes. It checks the `app` service tag and looks in the recipe catalogue versions list. If the `app` image tag is, say, `2.3.1` then we're looking for an `a.b.c` part of the `x.y.z+a.b.c` which matches? From there, we can do comparisons on the service tags and then ask the user - is this a minor/major/patch upgrade for the `x.y.z` part? (this is the un-automatable part, right?) - if there is no matching `a.b.c` part in the recipe catalogue then we can automate this release? We can follow the patch/minor/major of the upgrade and change the `x.y.z` part to match? Unfinished thoughts...think we should deffo try to break stuff down into small parts and then just test the shit out of it...down to plan a meeting in to chat about this!

knoflook referenced a pull request from coop-cloud/abra that will close this issue

2021-09-22 15:54:32 +00:00

feat: tag recipes with abra #99

decentral1se commented

2021-09-23 13:27:01 +00:00

Some notes from previous chat: https://pad.autonomic.zone/SX1Hs84mSDSkU6DZy2KdDA?both

We're also planning in a chat this coming tuesday to work out more details together.

Some notes from previous chat: https://pad.autonomic.zone/SX1Hs84mSDSkU6DZy2KdDA?both We're also planning in a chat this coming tuesday to work out more details together.

decentral1se closed this issue

2021-09-29 12:39:36 +00:00

Sign in to join this conversation.

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#135