Run automatic pre and post migration scripts #813

New Issue

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:
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 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!

🚀 1

decentral1se commented

2026-04-08 21:42:42 +00:00

![image.png](/attachments/8c9386eb-5033-4548-b18a-c72d2731db6e)

image.png

943 KiB

😆 3

simon commented

2026-04-09 07:25:38 +00:00

Guess we really should develop a plan on how to upstream alakazam features step by step 🤭

Guess we *really* should develop a plan on how to upstream alakazam features step by step 🤭

❤️ 2

notplants commented

2026-04-13 05:11:16 +00:00

give the version-number as an argument to a generic upgrade_pre_local script

this sounds more readable to me (to have one generic script that uses the version numbers as an argument), but both options sound good

I am not sure if it would be able to handle this case still, but it could handle a lot of things!

> 2. give the version-number as an argument to a generic upgrade_pre_local script this sounds more readable to me (to have one generic script that uses the version numbers as an argument), but both options sound good I am not sure if it would be able to handle [this](https://git.coopcloud.tech/toolshed/organising/issues/682#issuecomment-31411) case still, but it could handle a lot of things!

❤️ 1

moritz commented

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

We are doing this with alakazam, see here

What alakazam is missing are pre upgrade hooks and hooks bound to specific versions. I really like the idea to bound specific commands to specific versions. I don't have a strong opinion if the version should be part of the function name, which makes the complexity of the hook functions more simple or if it should be passed as argument.

I am not sure if it would be able to handle this case still, but it could handle a lot of things!

This could be handled by this proposal: #812

> We are doing this with alakazam, see [here](https://git.coopcloud.tech/moritz/alakazam#app-configuration) What alakazam is missing are pre upgrade hooks and hooks bound to specific versions. I really like the idea to bound specific commands to specific versions. I don't have a strong opinion if the version should be part of the function name, which makes the complexity of the hook functions more simple or if it should be passed as argument. > I am not sure if it would be able to handle [this](https://git.coopcloud.tech/toolshed/organising/issues/682#issuecomment-31411) case still, but it could handle a lot of things! This could be handled by this proposal: https://git.coopcloud.tech/toolshed/abra/issues/812

❤️ 2

p4u1 commented

2026-04-14 07:13:34 +00:00

For me the main argument in favor of having a separate upgrade function per version is that abra can convert next to the actual version.I don't have a very strong opinion though

ineiti commented

2026-06-14 17:58:50 +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 :)

sorry for the late reply - when doing upgrades, you can either describe every upgrade step you need to do, but this can get very long. If you have a function with the from_version and to_version, then the function can define itself whether it should update things in one go, split it by major/minor/patch versions, or whatever.

In the simplest case, the function loops over upgrade_${version} where version goes from from_version to to_version.

> @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 :) sorry for the late reply - when doing upgrades, you can either describe every upgrade step you need to do, but this can get very long. If you have a function with the `from_version` and `to_version`, then the function can define itself whether it should update things in one go, split it by major/minor/patch versions, or whatever. In the simplest case, the function loops over `upgrade_${version}` where `version` goes from `from_version` to `to_version`.

Sign in to join this conversation.

6 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>`