Run automatic pre and post migration scripts #813

New Issue

p4u1 · 2026-03-31T17:14:52Z

p4u1 commented

2026-03-31 17:14:52 +00:00

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

Problem:

I have to do manual steps when upgrading a recipe like:

enable and disable maintenance mode
rename secrets by hand or use scripts written by a heros
run a post migration step required after a major upgrade
check if all plugins are upgradable with the new version (looking at you nextcloud)

Solution:

Allow writing pre and post scripts in abra.sh. This way they could also be run manually (for example during testing).

Each upgrade can have up to four scripts, which are executed in the order as given here:

`upgrade_<version>_pre_local`:

Execute before actual upgrade locally

Equivalent abra command: abra app cmd example.com upgrade_1.0.0+1.0.0_pre_local --local

`upgrade_<version>_post_<service>`

Execute after actual upgrade in the given

Equivalent abra command: abra app cmd example.com app upgrade_1.0.0+1.0.0_post_app

`upgrade_<version>_post_local`

Execute after actual upgrade locally

Equivalent abra command: abra app cmd example.com app upgrade_1.0.0+1.0.0_post --local

Using next instead `<version>`

It is possible to use function names with out the actual version but instead with "next". When running abra recupe releaseallnext` upgrade functions will be coverted to functions. This is the same logic as with release notes

_Thanks Tobias Featherbutt for starting the discussion and for the great problem and solution statements_ ## Problem: I have to do manual steps when upgrading a recipe like: - enable and disable maintenance mode - rename secrets by hand or use [scripts written by a heros](https://git.coopcloud.tech/eCommons/monitoring-ng/src/branch/shorter-names/abra.sh#L29) - run a post migration step required after a major upgrade - check if all plugins are upgradable with the new version (looking at you nextcloud) ## Solution: Allow writing pre and post scripts in `abra.sh`. This way they could also be run manually (for example during testing). Each upgrade can have up to four scripts, which are executed in the order as given here: #### `upgrade_<version>_pre_local`: Execute before actual upgrade locally Equivalent abra command: `abra app cmd example.com upgrade_1.0.0+1.0.0_pre_local --local` #### `upgrade_<version>_post_<service>` Execute after actual upgrade in the given <service> Equivalent abra command: `abra app cmd example.com app upgrade_1.0.0+1.0.0_post_app` #### `upgrade_<version>_post_local` Execute after actual upgrade locally Equivalent abra command: `abra app cmd example.com app upgrade_1.0.0+1.0.0_post --local` ### Using next instead `<version>` It is possible to use function names with out the actual version but instead with "next". When running abra recupe release` all `next` upgrade functions will be coverted to <version> functions. This is the same logic as with release notes

🚀 2

p4u1 referenced this issue

2026-03-31 17:15:48 +00:00

abra app upgrade stability #811

p4u1 added a new dependency 2026-03-31 17:15:59 +00:00

#811 abra app upgrade stability

decentral1se commented

2026-03-31 18:19:48 +00:00

❤️ 2

decentral1se added the

enhancement

label 2026-03-31 18:20:32 +00:00

ineiti commented

2026-04-01 12:02:25 +00:00

Should we create a wiki page somewhere and start to note what kind of events people want to be able to subscribe to, where they could be found?

For this specific proposition, can @p4u1 give some pros and cons between:

put the version-number in the script name
give the version-number as an argument to a generic upgrade_pre_local script?

To me the second is more versatile, specifically if you want to pass from_version and to_version, which would give a lot of scripts...

Should we create a wiki page somewhere and start to note what kind of events people want to be able to subscribe to, where they could be found? For this specific proposition, can @p4u1 give some pros and cons between: 1. put the version-number in the script name 2. give the version-number as an argument to a generic `upgrade_pre_local` script? To me the second is more versatile, specifically if you want to pass `from_version` and `to_version`, which would give a lot of scripts...

p4u1 commented

2026-04-01 19:07:26 +00:00

@ineiti can you give a use case for 2? Also would it still be possible to name the version next and let Abra insert the actual version? I'm not strictly against the more generic entrypoint but still need to be convinced :)

p4u1 commented

2026-04-01 19:08:10 +00:00

Should we create a wiki page somewhere and start to note what kind of events people want to be able to subscribe to, where they could be found?

Maybe create a pad and then we can collaborate there?

> Should we create a wiki page somewhere and start to note what kind of events people want to be able to subscribe to, where they could be found? Maybe create a pad and then we can collaborate there?

simon commented

2026-04-07 10:41:51 +00:00

We are doing this with alakazam, see here

We have hooks for

initialization
post-deploy
post upgrade
secret generation

For example, the stuff we tell Nextcloud to do:
08e9f8ad9f/alaka-defaults.yml (L58-L71)

So we just write abra.sh functions and in our alaka-config, the syntax is <container> <function> <arguments>

A usecase for the secret-hook is vaultwarden or kimai

That way we also can run those manually again whenever needed. Works very reliable for us. Having more pre-hooks e.g. to check the Nextcloud apps would be nice though!

We are doing this with alakazam, see [here](https://git.coopcloud.tech/moritz/alakazam#app-configuration) We have hooks for - initialization - post-deploy - post upgrade - secret generation For example, the stuff we tell Nextcloud to do: https://git.local-it.org/local-it/kolli-config/src/commit/08e9f8ad9ff5c6300a0a694bc59159229a4d43fd/alaka-defaults.yml#L58-L71 So we just write abra.sh functions and in our alaka-config, the syntax is `<container> <function> <arguments>` A usecase for the secret-hook is [vaultwarden](https://git.local-it.org/local-it/kolli-config/src/commit/08e9f8ad9ff5c6300a0a694bc59159229a4d43fd/alaka-defaults.yml#L176-L177) or [kimai](https://git.coopcloud.tech/moritz/alakazam/src/commit/497b1e950b9482e6bf04d2fc59d950952ae7685c/combine.yml#L123-L124) That way we also can run those manually again whenever needed. Works very reliable for us. Having more pre-hooks e.g. to check the Nextcloud apps would be nice though!

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Blocks

#811 abra app upgrade stability

toolshed/abra

Reference: toolshed/abra#813

Run automatic pre and post migration scripts #813

Problem:

Solution:

upgrade_<version>_pre_local:

upgrade_<version>_post_<service>

upgrade_<version>_post_local

Using next instead <version>

`upgrade_<version>_pre_local`:

`upgrade_<version>_post_<service>`

`upgrade_<version>_post_local`

Using next instead `<version>`