Deal with nonskippable recipe updates #812

New Issue

2026-03-31T16:02:20Z

p4u1 commented

2026-03-31 16:02:20 +00:00

Thanks Tobias Featherbutt for starting the discussion and for the great problem and solution statements

Problem:

A recipes has 3 releases:

1.0.0+1.0.0
1.1.0+1.1.0
2.0.0+2.0.0

The upgrade to 2.0.0 is only guaranteed to be stable when upgrading from 1.1.0

An app is deployed at 1.0.0+1.0.0

abra app upgrade and the select 2.0.0 (because of course I want the latest version)

The app is broken because I skipped the 1.1.0+1.1.0 release

Solution:

Interpret recipe release notes as markdown

Check if an upgrade has nonskippable set to true in frontmatter:

---
nonskippable: true
---

abra app upgrade will not skip this upgrade instead it will do the nonskippable upgrade first and then do the actual upgrade.

_Thanks Tobias Featherbutt for starting the discussion and for the great problem and solution statements_ **Problem:** A recipes has 3 releases: 1.0.0+1.0.0 1.1.0+1.1.0 2.0.0+2.0.0 The upgrade to 2.0.0 is only guaranteed to be stable when upgrading from 1.1.0 An app is deployed at 1.0.0+1.0.0 abra app upgrade and the select 2.0.0 (because of course I want the latest version) The app is broken because I skipped the 1.1.0+1.1.0 release **Solution:** Interpret recipe release notes as markdown Check if an upgrade has `nonskippable` set to true in frontmatter: ``` --- nonskippable: true --- ``` abra app upgrade will not skip this upgrade instead it will do the nonskippable upgrade first and then do the actual upgrade.

🚀 1

p4u1 referenced this issue

2026-03-31 16:11:42 +00:00

abra app upgrade stability #811

moritz commented

2026-03-31 16:25:55 +00:00

I like the idea of automatic updates step by step updates until the desired version is reached.

How about tagging specific releases as nonskipable? In this case 1.1.0+1.1.0 would be the nonskipable release.
This way I could directly update from 1.0.0+1.0.0 to version 2.0.0+2.0.0 and abra would handle all necessary intermedate updates tagged with nonskipable.
This is somewhat behavior 2.) but instead of performing upgrades of all intermediate versions, only the nonskipable will be executed. Sometimes we do an update skipping 10 versions. If abra would do an step by step update for each intermediated version it would take very long and the risks for some failures would increase.

I like the idea of automatic updates step by step updates until the desired version is reached. How about tagging specific releases as `nonskipable`? In this case ` 1.1.0+1.1.0` would be the `nonskipable` release. This way I could directly update from `1.0.0+1.0.0` to version ` 2.0.0+2.0.0` and abra would handle all necessary intermedate updates tagged with `nonskipable`. This is somewhat behavior 2.) but instead of performing upgrades of all intermediate versions, only the `nonskipable` will be executed. Sometimes we do an update skipping 10 versions. If abra would do an step by step update for each intermediated version it would take very long and the risks for some failures would increase.

❤️ 2

p4u1 commented

2026-03-31 16:52:51 +00:00

Nice I like your idea! How about we treat release notes as markdown? Then we can add frontmatter like this:

---
nonskippable: true
---

This would also allow the posibility to add more metadata like broken to a release. And this allows an easy way to edit previous releases

Nice I like your idea! How about we treat release notes as markdown? Then we can add frontmatter like this: ``` --- nonskippable: true --- ``` This would also allow the posibility to add more metadata like `broken` to a release. And this allows an easy way to edit previous releases

👍 1

p4u1 changed title from ~~introduce ABRA_SKIP_UPGRADES=false~~ to Deal with nonskippable recipe updates

2026-03-31 16:53:15 +00:00

p4u1 added a new dependency 2026-03-31 16:58:24 +00:00

#811 abra app upgrade stability

decentral1se added the enhancement label 2026-03-31 18:20:26 +00:00

moritz referenced this issue

2026-04-13 12:55:59 +00:00

Run automatic pre and post migration scripts #813

decentral1se commented

2026-04-16 10:37:39 +00:00

I like the release note markdown proposal. However, we some times have bugs in that notes logic with abra #807 😬 We will fix / close this regression down with unit/integration tests eventually but I would look for a less fragile way to enforce nonskippable. Could this be done in the tag name?

I like the release note markdown proposal. However, we some times have bugs in that notes logic with `abra` https://git.coopcloud.tech/toolshed/abra/issues/807 😬 We will fix / close this regression down with unit/integration tests eventually but I would look for a less fragile way to enforce `nonskippable`. Could this be done in the tag name?

👍 1

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Blocks

#811 abra app upgrade stability

toolshed/abra

Reference: toolshed/abra#812