toolshed/abra
toolshed/abra
4
2
Fork 18
Code Issues 27 Pull Requests 3 Packages Releases 40 Activity

Sync to minor version skips one version? #482

New Issue
Closed
opened 2025-01-09 20:09:00 +00:00 by fauno · 2 comments
fauno commented 2025-01-09 20:09:00 +00:00
Member
Copy Link

I ran abra recipe sync for the gitea recipe with abra 0.10, telling it it's a minor upgrade and it jumped from 3.0.1 to 3.2.0 while I would expect it to go to 3.1.0.

It didn't ask me if it was a stable or unstable upgrade, if it follows even/odd numbering (which I'm not really sure is part of semver or not).

I ran `abra recipe sync` for the gitea recipe with abra 0.10, telling it it's a minor upgrade and it jumped from 3.0.1 to 3.2.0 while I would expect it to go to 3.1.0. It didn't ask me if it was a stable or unstable upgrade, if it follows even/odd numbering (which I'm not really sure is part of semver or not).
decentral1se commented 2025-01-09 21:38:03 +00:00
Owner
Copy Link

@fauno just had a test of this, I'm unable to reproduce it.

Can you provide some --debug output? This kind of behaviour is quite heavily tested, so I wouldn't expect a bug like this. Maybe there is some different state in your local recipe repository?

Here's my manual testing logs.

abra recipe sync gitea -d
DEBU <cli/run.go:60> abra version 0.10.0-rc1-beta, commit 8af87aa38216c45a36135771755be187c66911ad
DEBU <git/read.go:149> read global ignore paths: ...
DEBU <git/read.go:52> git status: /home/d/.abra/recipes/gitea: clean
DEBU <internal/validate.go:81> validated gitea as recipe argument
DEBU <formatter/formatter.go:237> stripped library/postgres to postgres for parsing
DEBU <recipe/git.go:348> detected 1.0.0+1.14.5-rootless, 1.1.0+1.15.0-rootless, 1.1.1+1.15.3-rootless, 1.1.2+1.15.6-rootless, 1.1.3+1.15.10-rootless, 1.2.0+1.16.3-rootless, 1.2.1+1.16.8-rootless, 1.3.0+1.17.2-rootless, 1.3.1+1.17.3-rootless, 2.0.0+1.18.0-rootless, 2.0.1+1.18.2-rootless, 2.1.0+1.18.5-rootless, 2.1.2+1.19.3-rootless, 2.10.0+1.22.1-rootless, 2.10.1+1.22.2-rootless, 2.11.0+1.22.2-rootless, 2.2.0+1.19.3-rootless, 2.3.0+1.20.1-rootless, 2.3.1+1.20.1-rootless, 2.3.2+1.20.3-rootless, 2.3.3+1.20.5-rootless, 2.4.0+1.21.0-rootless, 2.5.0+1.21.1-rootless, 2.5.1+1.21.4-rootless, 2.5.2+1.21.5-rootless, 2.6.0+1.21.5-rootless, 2.6.1+1.21.10-rootless, 2.6.2+1.21.10-rootless, 2.7.0+1.21.11-rootless, 2.8.0+1.21.11-rootless, 2.9.0+1.22.0-rootless, 2.9.1+1.22.0-rootless, 3.0.0+1.22.2-rootless, 3.0.1+1.22.3-rootless, 3.0.2+1.22.6-rootless as tags for recipe gitea

You need to make a decision about what kind of an update this new recipe
version is. If someone else performs this upgrade, do they have to do some
migration work or take care of some breaking changes? This can be signaled in
the version you specify on the recipe deploy label and is called a semantic
version.

The latest published version is 3.0.2+1.22.6-rootless.

Here is a semver cheat sheet (more on https://semver.org):

    major: new features/bug fixes, backwards incompatible (e.g 1.0.0 -> 2.0.0).
           the upgrade won't work without some preparation work and others need
           to take care when performing it. "it could go wrong".

    minor: new features/bug fixes, backwards compatible (e.g. 0.1.0 -> 0.2.0).
           the upgrade should Just Work and there are no breaking changes in
           the app and the recipe config. "it should go fine".

    patch: bug fixes, backwards compatible (e.g. 0.0.1 -> 0.0.2). this upgrade
           should also Just Work and is mostly to do with minor bug fixes
           and/or security patches. "nothing to worry about".

? select recipe version increment type minor
DEBU <recipe/sync.go:187> choosing 3.1.0+1.22.6-rootless as new version for gitea
DEBU <recipe/compose.go:189> considering /home/d/.abra/recipes/gitea/compose.yml config(s) for label update
DEBU <recipe/compose.go:235> updating coop-cloud.${STACK_NAME}.version=3.0.2+1.22.6-rootless to coop-cloud.${STACK_NAME}.version=3.1.0+1.22.6-rootless in /home/d/.abra/recipes/gitea/compose.yml
INFO <recipe/compose.go:241> synced label coop-cloud.${STACK_NAME}.version=3.1.0+1.22.6-rootless to service app
DEBU <git/read.go:149> read global ignore paths: ...
DEBU <git/read.go:50> git status: /home/d/.abra/recipes/gitea:  M compose.yml
INFO <recipe/sync.go:210> gitea currently has these unstaged changes 👇
diff --git a/compose.yml b/compose.yml
index ca9d8ff..ed2e673 100644
--- a/compose.yml
+++ b/compose.yml
@@ -84,7 +84,7 @@ services:
         - "traefik.http.middlewares.${STACK_NAME}_cors.headers.accesscontrolalloworiginlist=https://${GITEA_CORS_ALLOW_DOMAIN}"
         - "traefik.http.middlewares.${STACK_NAME}_cors.headers.accesscontrolmaxage=100"
         - "traefik.http.middlewares.${STACK_NAME}_cors.headers.addvaryheader=true"
-        - coop-cloud.${STACK_NAME}.version=3.0.2+1.22.6-rootless
+        - coop-cloud.${STACK_NAME}.version=3.1.0+1.22.6-rootless


 networks:

And all the local tags:

git -C ~/.abra/recipes/gitea tag -l
1.0.0+1.14.5-rootless
1.1.0+1.15.0-rootless
1.1.1+1.15.3-rootless
1.1.2+1.15.6-rootless
1.1.3+1.15.10-rootless
1.2.0+1.16.3-rootless
1.2.1+1.16.8-rootless
1.3.0+1.17.2-rootless
1.3.1+1.17.3-rootless
2.0.0+1.18.0-rootless
2.0.1+1.18.2-rootless
2.1.0+1.18.5-rootless
2.1.2+1.19.3-rootless
2.10.0+1.22.1-rootless
2.10.1+1.22.2-rootless
2.11.0+1.22.2-rootless
2.2.0+1.19.3-rootless
2.3.0+1.20.1-rootless
2.3.1+1.20.1-rootless
2.3.2+1.20.3-rootless
2.3.3+1.20.5-rootless
2.4.0+1.21.0-rootless
2.5.0+1.21.1-rootless
2.5.1+1.21.4-rootless
2.5.2+1.21.5-rootless
2.6.0+1.21.5-rootless
2.6.1+1.21.10-rootless
2.6.2+1.21.10-rootless
2.7.0+1.21.11-rootless
2.8.0+1.21.11-rootless
2.9.0+1.22.0-rootless
2.9.1+1.22.0-rootless
3.0.0+1.22.2-rootless
3.0.1+1.22.3-rootless
3.0.2+1.22.6-rootless
@fauno just had a test of this, I'm unable to reproduce it. Can you provide some `--debug` output? This kind of behaviour is quite heavily tested, so I wouldn't expect a bug like this. Maybe there is some different state in your local recipe repository? Here's my manual testing logs. ``` abra recipe sync gitea -d DEBU <cli/run.go:60> abra version 0.10.0-rc1-beta, commit 8af87aa38216c45a36135771755be187c66911ad DEBU <git/read.go:149> read global ignore paths: ... DEBU <git/read.go:52> git status: /home/d/.abra/recipes/gitea: clean DEBU <internal/validate.go:81> validated gitea as recipe argument DEBU <formatter/formatter.go:237> stripped library/postgres to postgres for parsing DEBU <recipe/git.go:348> detected 1.0.0+1.14.5-rootless, 1.1.0+1.15.0-rootless, 1.1.1+1.15.3-rootless, 1.1.2+1.15.6-rootless, 1.1.3+1.15.10-rootless, 1.2.0+1.16.3-rootless, 1.2.1+1.16.8-rootless, 1.3.0+1.17.2-rootless, 1.3.1+1.17.3-rootless, 2.0.0+1.18.0-rootless, 2.0.1+1.18.2-rootless, 2.1.0+1.18.5-rootless, 2.1.2+1.19.3-rootless, 2.10.0+1.22.1-rootless, 2.10.1+1.22.2-rootless, 2.11.0+1.22.2-rootless, 2.2.0+1.19.3-rootless, 2.3.0+1.20.1-rootless, 2.3.1+1.20.1-rootless, 2.3.2+1.20.3-rootless, 2.3.3+1.20.5-rootless, 2.4.0+1.21.0-rootless, 2.5.0+1.21.1-rootless, 2.5.1+1.21.4-rootless, 2.5.2+1.21.5-rootless, 2.6.0+1.21.5-rootless, 2.6.1+1.21.10-rootless, 2.6.2+1.21.10-rootless, 2.7.0+1.21.11-rootless, 2.8.0+1.21.11-rootless, 2.9.0+1.22.0-rootless, 2.9.1+1.22.0-rootless, 3.0.0+1.22.2-rootless, 3.0.1+1.22.3-rootless, 3.0.2+1.22.6-rootless as tags for recipe gitea You need to make a decision about what kind of an update this new recipe version is. If someone else performs this upgrade, do they have to do some migration work or take care of some breaking changes? This can be signaled in the version you specify on the recipe deploy label and is called a semantic version. The latest published version is 3.0.2+1.22.6-rootless. Here is a semver cheat sheet (more on https://semver.org): major: new features/bug fixes, backwards incompatible (e.g 1.0.0 -> 2.0.0). the upgrade won't work without some preparation work and others need to take care when performing it. "it could go wrong". minor: new features/bug fixes, backwards compatible (e.g. 0.1.0 -> 0.2.0). the upgrade should Just Work and there are no breaking changes in the app and the recipe config. "it should go fine". patch: bug fixes, backwards compatible (e.g. 0.0.1 -> 0.0.2). this upgrade should also Just Work and is mostly to do with minor bug fixes and/or security patches. "nothing to worry about". ? select recipe version increment type minor DEBU <recipe/sync.go:187> choosing 3.1.0+1.22.6-rootless as new version for gitea DEBU <recipe/compose.go:189> considering /home/d/.abra/recipes/gitea/compose.yml config(s) for label update DEBU <recipe/compose.go:235> updating coop-cloud.${STACK_NAME}.version=3.0.2+1.22.6-rootless to coop-cloud.${STACK_NAME}.version=3.1.0+1.22.6-rootless in /home/d/.abra/recipes/gitea/compose.yml INFO <recipe/compose.go:241> synced label coop-cloud.${STACK_NAME}.version=3.1.0+1.22.6-rootless to service app DEBU <git/read.go:149> read global ignore paths: ... DEBU <git/read.go:50> git status: /home/d/.abra/recipes/gitea: M compose.yml INFO <recipe/sync.go:210> gitea currently has these unstaged changes 👇 diff --git a/compose.yml b/compose.yml index ca9d8ff..ed2e673 100644 --- a/compose.yml +++ b/compose.yml @@ -84,7 +84,7 @@ services: - "traefik.http.middlewares.${STACK_NAME}_cors.headers.accesscontrolalloworiginlist=https://${GITEA_CORS_ALLOW_DOMAIN}" - "traefik.http.middlewares.${STACK_NAME}_cors.headers.accesscontrolmaxage=100" - "traefik.http.middlewares.${STACK_NAME}_cors.headers.addvaryheader=true" - - coop-cloud.${STACK_NAME}.version=3.0.2+1.22.6-rootless + - coop-cloud.${STACK_NAME}.version=3.1.0+1.22.6-rootless networks: ``` And all the local tags: ``` git -C ~/.abra/recipes/gitea tag -l 1.0.0+1.14.5-rootless 1.1.0+1.15.0-rootless 1.1.1+1.15.3-rootless 1.1.2+1.15.6-rootless 1.1.3+1.15.10-rootless 1.2.0+1.16.3-rootless 1.2.1+1.16.8-rootless 1.3.0+1.17.2-rootless 1.3.1+1.17.3-rootless 2.0.0+1.18.0-rootless 2.0.1+1.18.2-rootless 2.1.0+1.18.5-rootless 2.1.2+1.19.3-rootless 2.10.0+1.22.1-rootless 2.10.1+1.22.2-rootless 2.11.0+1.22.2-rootless 2.2.0+1.19.3-rootless 2.3.0+1.20.1-rootless 2.3.1+1.20.1-rootless 2.3.2+1.20.3-rootless 2.3.3+1.20.5-rootless 2.4.0+1.21.0-rootless 2.5.0+1.21.1-rootless 2.5.1+1.21.4-rootless 2.5.2+1.21.5-rootless 2.6.0+1.21.5-rootless 2.6.1+1.21.10-rootless 2.6.2+1.21.10-rootless 2.7.0+1.21.11-rootless 2.8.0+1.21.11-rootless 2.9.0+1.22.0-rootless 2.9.1+1.22.0-rootless 3.0.0+1.22.2-rootless 3.0.1+1.22.3-rootless 3.0.2+1.22.6-rootless ```
decentral1se added the
question
 label 2025-01-09 21:39:16 +00:00
fauno commented 2025-01-13 12:48:20 +00:00
Author
Member
Copy Link

Ooooh sorry to make you spend time on this!! I forgot I already had tagged internally to 3.1.0 on another branch :/

Ooooh sorry to make you spend time on this!! I forgot I already had tagged internally to 3.1.0 on another branch :/
🚀 1
fauno closed this issue 2025-01-13 12:48:20 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
build
go build related issues
ci/cd
Building things with CI/CD
contributing
Dealing with contributing
critical fix
https://docs.coopcloud.tech/federation/resolutions/passed/010/
design
UI/UX
documentation
Documenting all the things
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
invalid
Something is wrong
meta
relating to the project or repo itself
question
More information is needed
release
Release management
release-candidate
Related to the new release candidate
security
Security related
test
Unit/integration testing
wontfix
This won't be fixed
No Label
question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm cas decentral1se fauno kawaiipunk knoflook lambdabundesverband moritz p4u1 simon trav val yksflip
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#482
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?