Updater is not detecting minor upgrade, when available (example: from version 1.0.0+0.0.5
to 1.0.0+0.0.11
)
#638
Loading…
x
Reference in New Issue
Block a user
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?
Old version of the deployed app:
1.0.0+0.0.5
defined in the recipe, here:
New version:
1.0.0+0.0.11
defined in the recipe, here
What happens now is:
INFO[0001] no available upgrades, you're on latest (1.0.0+0.0.5) ✌
Verbose output:
What I wish abra to do, instead of erroring, is:
Tech details
the function responsible for this seems to be in the updater.go,
this line seems not working properly:
versionDelta, err := parsedDeployedVersion.UpgradeDelta(parsedVersion)
from this package: https://git.coopcloud.tech/coop-cloud/tagcmp
--> it is not seeing
1.0.0+0.0.11
as bigger than 1.0.0+0.0.5
and then, based on that output, abra assumes that the app is already running on the last version
extract from updater.go
All of the versioning stuff relies on the recipe catalogue, which doesn't seem to include open-inventory:
My guess is that it's because the open-inventory recipe repo doesn't include the
recipe
"topic" label. Adding that, and regenerating the recipe catalogue (either by waiting for the daily regen, or by launching a new build ofauto-recipes-catalogue-json
on Drone), should fix it.The recipe version should always be bumped as well (with
abra recipe sync
), so the correct upgrade version should have been e.g.1.0.1+0.0.11
.To handle this problem, I think it would be more correct if
abra release
will fail if there is already a published version with the same first part of the version (here1.0.0
)We're in a bit of a transition moment with how we're doing recipe releasing, so thanks for patience on this one. Will try to come back on this when the dust settles and the new
abra
release is out and the migration dust settles #666.