Release channels for auto updates of apps

[andreasdueren]

It would be nice to be able to select release channels for apps, even better if adjustable per app install. So for example if I want cutting edge updates, I can select that. If I want stable (could be one or two releases behind) then I select that.

Especially for mission critical apps it would be nice to not auto-update to a version which has not been tested yet.

[james]

Hello @andreasdueren

These are my opinions and my thoughts for this feature request.

---

Doing this would increase the Cloudron staff workload with a multiplication factor for each app.
Currently, in the App Store are 180 apps.
https://www.cloudron.io/store/index.html browser console JavaScript:

document.getElementsByClassName("item").length
180

Let's say, for each app update, checking the pipeline CI/CD for failures and if no failure is obvious, evaluating if everything is indeed correct and deploying this to the App Store, takes 10 Minutes for each app (optimistically).

For 180 app:

10m * 180apps = 1800m / 60 = 30h

So, if everything is going smooth, 30 hours for all apps.

Now, let's say each app had just a beta channel, this would make it 30 hours * 2, so 60 hours.
Since there could be beta and alpha or more channels, this could get out of hand very quickly.
Not to mention, some apps don't even have a release channel and work with just "latest" git commit.

And this is for "each app update has no issues".
You can imagine that some complex apps like Nextcloud or others can produce issues almost for each update even on the stable release channel.
Evaluating this, for each release channel, which are going to change faster than stable and have potentially more issues, is simply not feasible.

---

Yes, unstable, alpha, beta channels could be ignored and not checked in depth like we do it with stable app updates.
Still, the support effort would increase, I suspected.
Case: Someone disabled auto backups for his production WordPress, now he wants to use the latest alpha release, this alpha release scrambles the Database and messes something up.
Backup missing, support ticket / forum post created.

No backup, no mercy! or You were informed this is alpha and could break things will still lead to unhappy Cloudron customers.

---

Now to a more optimistic answer with labor on the user end.

If one does really need these cutting edge updates for certain apps now, these can be done by the user himself.
Updating an app, which was installed from the App Store, with the cloudron-cli to a custom image and a custom CloudronManifest.json is possible.
And updating this custom app back to an app store default.
Meaning, yes you can clone e.g. the wordpress-managed-app, change the:

ARG WORDPRESS_VERSION=6.8.2
[...]
ARG WPCLI_VERSION=2.12.0

and CloudronManifest.json

{
[...]
  "version": "3.13.3",
  "upstreamVersion": "6.8.2",
[...]
}

To the version of your need, build the image, upload the image to e.g. Docker hub / other Docker Registry or use the Cloudron Docker Registry app with the Cloudron Docker Remote Builder app and update (in a perfect world scenario) your app clone.

cloudron update --app $APPID --image $DOCKERHUBID/$(yq -r .id CloudronManifest.json):$(yq -r .version CloudronManifest.json)

After testing and using this custom app update.
You can even revert to the App Store default with:

cloudron update --app $APPID --appstore-id <appid[@version]>

[girish]

@james some great math there But right, I think the amount of work to have multiple channels is quite astronomical. I think definitely people will also want to switch between channels easily -- all this will be untested by us. Say, moving from discourse beta to stable etc

We will look into adding the custom Appstores though (ties into the other CUR thread). This way enthusiasts can run beta/alpha repositories.

[andreasdueren]

@girish im not asking for an additional beta Chanel but rather a stable Chanel which is a predetermined amount of updates behind

[james]

Oh! You mean like, Cloudron app release channel?
All app updates should be considered stable. Only apps marked as "unstable" are indeed unstable.
Or did I not understand the proposal again?

[andreasdueren]

@james yes they should be but there have been various incidents in the past where automatic updates broke installs. Not blaming anyone, that’s just in the nature of things. So giving people the option to stay behind one release for mission critical deployments where people have had experience with any potentials issues would be nice to have I believe.

[james]

@andreasdueren
If app updates fail and break apps, please always report this.

I highly suspect the apps that might break, even after our tests to be apps that are highly customizable and/or extendable.
Again, a good example is Nextcloud.
Covering every plugin in our tests and each plugin in combination with another plugins, is simply not feasible.

---

For a fast solution now, you can disable automatic app updates for mission-critical apps.
You will still see an update is available and can create a backup, clone from the latest backup and test the update in the clone.

[girish]

@andreasdueren said in Release channels for auto updates of apps:

@girish im not asking for an additional beta Chanel but rather a stable Chanel which is a predetermined amount of updates behind

As @james said all Updates are technically "stable" because we only release after the tests passed.

But of course: Cloudron releases new packages as soon as the upstream makes a release and the nature of open source is that more likely than not this has regressions and bugs. I think we recognize having some "be conservative" with updating this app will be nice to have.

Maybe we can discuss this more. Is a time based Window better? Like only update have after 1 month has passed or always be 2 releases behind or something like that? Another idea is to say always be in the latest of the previous minor release. But from experience , practically nobody follows semver properly. The newer apps in fact release new features and break things in newer versions that is not easily guessable from the version (Even "enterprise" apps like minio).

I think a separate complication (for us) is how we can ever support this Our app packages are a rolling release model and jumping from one minor latest to next minor latest is not possible easily since it's not tested.

[andreasdueren]

@girish Yes a time based window would also be good. So only update if update is > Time old. Whatever is a simple implementation.