chore(deps): update pgautoupgrade/pgautoupgrade docker tag to v18 #85

2026-06-10T10:17:39Z

renovate-bot commented

2026-06-10 10:17:39 +00:00

This PR contains the following updates:

Package	Update	Change
pgautoupgrade/pgautoupgrade	major	`17-debian` -> `18-debian`

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | pgautoupgrade/pgautoupgrade | major | `17-debian` -> `18-debian` | --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

ineiti commented

2026-07-25 19:43:40 +00:00

Is anybody using postgresql and can test if this works?

ineiti added the help wanted label 2026-07-25 19:44:03 +00:00

maren commented

2026-07-28 20:07:23 +00:00

First-time contributor

We are using postgresql and have had some issues with the change that preceded this, from the upstream postgres image to the autoupgrade container. one thing that will certainly break here is that the mount path for the data volume changes in version 18, from /var/lib/postresql/data to var/lib/postgresql

this is also a sudden update across 4 major versions of postgres, which historically does not update across versions easily (which is what motivated the change to the autoupgrade container). i think it's too big of an update.

is there a precedent for other recipes when they update their database versions? we do need to update the postgres container, but i'd like to have more of a plan than just allowing renovated bot to bump us 4 versions.

We are using postgresql and have had some issues with the change that preceded this, from the upstream postgres image to the autoupgrade container. one thing that will certainly break here is that the mount path for the data volume changes in version 18, from /var/lib/postresql/data to var/lib/postgresql this is also a sudden update across 4 major versions of postgres, which historically does not update across versions easily (which is what motivated the change to the autoupgrade container). i think it's too big of an update. is there a precedent for other recipes when they update their database versions? we do need to update the postgres container, but i'd like to have more of a plan than just allowing renovated bot to bump us 4 versions.

renovate-bot force-pushed renovate/pgautoupgrade-pgautoupgrade-18.x from 07185ef4e9 to d5e0064c74

2026-08-02 15:17:31 +00:00

Compare

ineiti commented

2026-08-04 10:55:55 +00:00

I'm planning (very soon, fingers crossed) to merge my draft I'm using in production for v34 to this repo, but in two steps: first v33, adding a v32 "use latest" version, then v34, adding a v33 "use latest" version.

I could either

go from v14 to v16 in v33
go from v16 to v18 in v34

or

go from v14 to v15 in v33
go from v15 to v16 in v34

But in the latter case we'd still be two versions behind. Do you have any preference? Would you be able to test this out on a production system?

I'm planning (very soon, fingers crossed) to merge my draft I'm using in production for v34 to this repo, but in two steps: first v33, adding a v32 "use latest" version, then v34, adding a v33 "use latest" version. I could either - go from v14 to v16 in v33 - go from v16 to v18 in v34 or - go from v14 to v15 in v33 - go from v15 to v16 in v34 But in the latter case we'd still be two versions behind. Do you have any preference? Would you be able to test this out on a production system?

oxaliq requested changes 2026-08-05 19:38:29 +00:00

oxaliq left a comment

i've confirmed that upgrade from 14 to 17 works. i would ask that the upgrade from 17 to 18 be a different release as this is the upgrade that changes the mount point and i ran into issues with it on testing

compose.postgres.yml Outdated

						
				@@ -23,5 +23,5 @@

				      - db_password

				    healthcheck:

				      test: ["CMD-SHELL", "pg_isready", "-U", "nextcloud"]

				      interval: 10s

				      timeout: 5s

oxaliq commented

2026-08-05 19:36:55 +00:00

this will need to be updated. i haven't looked into why, but the healthcheck is not being parsed correctly in list form and is trying to run as the "root" role in postgres.

changing to this resolves the issue:
test: ["CMD-SHELL", "pg_isready -U nextcloud -d nextcloud"]

this will need to be updated. i haven't looked into why, but the healthcheck is not being parsed correctly in list form and is trying to run as the "root" role in postgres. changing to this resolves the issue: `test: ["CMD-SHELL", "pg_isready -U nextcloud -d nextcloud"]`

oxaliq commented

2026-08-05 19:43:57 +00:00

@ineiti i'm at the same co-op as @maren and she's out of office, so i can speak to our preference being:

bump from 14 to 17 in v33
bump from 17 to 18 (hopefully) in v34

@ineiti i'm at the same co-op as @maren and she's out of office, so i can speak to our preference being: - bump from 14 to 17 in v33 - bump from 17 to 18 (hopefully) in v34

ineiti commented

2026-08-06 09:35:20 +00:00

i've confirmed that upgrade from 14 to 17 works. i would ask that the upgrade from 17 to 18 be a different release as this is the upgrade that changes the mount point and i ran into issues with it on testing

Here is the documentation for healthcheck:

https://docs.docker.com/reference/compose-file/services/#healthcheck

Using CMD-SHELL runs the command configured as a string using the container's default shell (/bin/sh for Linux).

So the question is more "why did it work before?". To me it looks like with the full arguments it only ran pg_isready...

> i've confirmed that upgrade from 14 to 17 works. i would ask that the upgrade from 17 to 18 be a different release as this is the upgrade that changes the mount point and i ran into issues with it on testing Here is the documentation for `healthcheck`: https://docs.docker.com/reference/compose-file/services/#healthcheck > Using CMD-SHELL runs the command configured as a string using the container's default shell (/bin/sh for Linux). So the question is more "why did it work before?". To me it looks like with the full arguments it only ran `pg_isready`...

ineiti commented

2026-08-06 09:35:52 +00:00

I hope I can create a first PR this evening and ask @dannygroenewegen to test it, too.

dannygroenewegen commented

2026-08-06 10:24:11 +00:00

I would also go for releasing v33. Then release a recipe for PG upgrade to v17.

I'm planning (very soon, fingers crossed) to merge my draft I'm using in production for v34 to this repo, but in two steps: first v33, adding a v32 "use latest" version, then v34, adding a v33 "use latest" version.

I saw another approach for the "use latest" we discussed in MAINTENANCE.MD. See Bonfire recipe compose.yml:

		bonfire/compose.yml
		Line 6 in 48e7e26bb0
	
				    image: ${CONTAINER_REGISTRY:-bonfirenetworks/bonfire}:${APP_VERSION:-1.0.6}-${APP_FLAVOUR:-social}-${APP_PLATFORM:-amd64}

We could add a commented-out env for nc_version_override that overrides the image tag. Then we don't have to do a "use latest" release for every major. And it allows for setting this env to v32 while still getting other recipe updates. What do you think?

I would also go for releasing v33. Then release a recipe for PG upgrade to v17. > I'm planning (very soon, fingers crossed) to merge my draft I'm using in production for v34 to this repo, but in two steps: first v33, adding a v32 "use latest" version, then v34, adding a v33 "use latest" version. I saw another approach for the "use latest" we discussed in MAINTENANCE.MD. See Bonfire recipe compose.yml: https://git.coopcloud.tech/coop-cloud/bonfire/src/commit/48e7e26bb0a004b443655449264331f49612f0f6/compose.yml#L6 We could add a commented-out env for `nc_version_override` that overrides the image tag. Then we don't have to do a "use latest" release for every major. And it allows for setting this env to v32 while still getting other recipe updates. What do you think?

ineiti commented

2026-08-06 10:43:30 +00:00

I would also go for releasing v33. Then release a recipe for PG upgrade to v17.

I thought of doing both at the same time: a PR which updates to v33 and PG to v17 at the same time. But I'm not sure how people usually update their services.

I saw another approach for the "use latest" we discussed in MAINTENANCE.MD. See Bonfire recipe compose.yml:

bonfire/compose.yml Line 6 in 48e7e26bb0

image: ${CONTAINER_REGISTRY:-bonfirenetworks/bonfire}:${APP_VERSION:-1.0.6}-${APP_FLAVOUR:-social}-${APP_PLATFORM:-amd64}

We could add a commented-out env for nc_version_override that overrides the image tag. Then we don't have to do a "use latest" release for every major. And it allows for setting this env to v32 while still getting other recipe updates. What do you think?

What would be the advantage over having a specific tag for the "use latest" v32? To me this looks too error-prone, specifically if people start to change the versions in their .env files by themselves, and then file a bug... But perhaps I'm missing something?

> I would also go for releasing v33. Then release a recipe for PG upgrade to v17. I thought of doing both at the same time: a PR which updates to v33 and PG to v17 at the same time. But I'm not sure how people usually update their services. > I saw another approach for the "use latest" we discussed in MAINTENANCE.MD. See Bonfire recipe compose.yml: > https://git.coopcloud.tech/coop-cloud/bonfire/src/commit/48e7e26bb0a004b443655449264331f49612f0f6/compose.yml#L6 > > We could add a commented-out env for `nc_version_override` that overrides the image tag. Then we don't have to do a "use latest" release for every major. And it allows for setting this env to v32 while still getting other recipe updates. What do you think? What would be the advantage over having a specific tag for the "use latest" v32? To me this looks too error-prone, specifically if people start to change the versions in their .env files by themselves, and then file a bug... But perhaps I'm missing something?

dannygroenewegen commented

2026-08-06 11:02:45 +00:00

I thought of doing both at the same time: a PR which updates to v33 and PG to v17 at the same time. But I'm not sure how people usually update their services.

Can't quickly find a source, but I thought the experience was not to do two major updates in one release if it can be avoided. If something breaks during the upgrade, you have two places to look.

What would be the advantage over having a specific tag for the "use latest" v32? To me this looks too error-prone, specifically if people start to change the versions in their .env files by themselves, and then file a bug... But perhaps I'm missing something?

It's indeed more error-prone. The advantage would be that we don't have to release a "use latest" for every vX. And it would allow people to stay on v32 while still using the latest recipe release, which could include other updates.

> I thought of doing both at the same time: a PR which updates to v33 and PG to v17 at the same time. But I'm not sure how people usually update their services. Can't quickly find a source, but I thought the experience was not to do two major updates in one release if it can be avoided. If something breaks during the upgrade, you have two places to look. > What would be the advantage over having a specific tag for the "use latest" v32? To me this looks too error-prone, specifically if people start to change the versions in their .env files by themselves, and then file a bug... But perhaps I'm missing something? It's indeed more error-prone. The advantage would be that we don't have to release a "use latest" for every vX. And it would allow people to stay on v32 while still using the latest recipe release, which could include other updates.

ineiti commented

2026-08-06 11:12:31 +00:00

I thought of doing both at the same time: a PR which updates to v33 and PG to v17 at the same time. But I'm not sure how people usually update their services.

Can't quickly find a source, but I thought the experience was not to do two major updates in one release if it can be avoided. If something breaks during the upgrade, you have two places to look.

So you propose to create a:

13.2.0+33.0.7-fpm with the pg14
13.2.1+33.0.7-fpm with the pg17

?

What would be the advantage over having a specific tag for the "use latest" v32? To me this looks too error-prone, specifically if people start to change the versions in their .env files by themselves, and then file a bug... But perhaps I'm missing something?

It's indeed more error-prone. The advantage would be that we don't have to release a "use latest" for every vX. And it would allow people to stay on v32 while still using the latest recipe release, which could include other updates.

Now we need to find a consensus :) If you feel that would be really good, let's do it. A middle-way would be to keep the current fixed-versions for 'normal' releases, and then only do the variables in 13.1.5+32.0.13-fpm.

I'm really scared of bug reports from the tag 13.1.5+32.0.13-fpm pointing to another version... Also, if you do abra app ls -S, you can see the versions, but with the variables, you're not sure anymore what the versions are!

> > I thought of doing both at the same time: a PR which updates to v33 and PG to v17 at the same time. But I'm not sure how people usually update their services. > > Can't quickly find a source, but I thought the experience was not to do two major updates in one release if it can be avoided. If something breaks during the upgrade, you have two places to look. So you propose to create a: - 13.2.0+33.0.7-fpm with the pg14 - 13.2.1+33.0.7-fpm with the pg17 ? > > What would be the advantage over having a specific tag for the "use latest" v32? To me this looks too error-prone, specifically if people start to change the versions in their .env files by themselves, and then file a bug... But perhaps I'm missing something? > > It's indeed more error-prone. The advantage would be that we don't have to release a "use latest" for every vX. And it would allow people to stay on v32 while still using the latest recipe release, which could include other updates. Now we need to find a consensus :) If you feel that would be _really_ good, let's do it. A middle-way would be to keep the current fixed-versions for 'normal' releases, and then only do the variables in `13.1.5+32.0.13-fpm`. I'm really scared of bug reports from the tag `13.1.5+32.0.13-fpm` pointing to another version... Also, if you do `abra app ls -S`, you can see the versions, but with the variables, you're not sure anymore what the versions are!

dannygroenewegen commented

2026-08-06 11:25:35 +00:00

I'm really scared of bug reports from the tag 13.1.5+32.0.13-fpm pointing to another version... Also, if you do abra app ls -S, you can see the versions, but with the variables, you're not sure anymore what the versions are!

I'm not so scared of bug reports, but the visibility of what's running is a good point. Let's stick to a use latest release.

So you propose to create a:

13.2.0+33.0.7-fpm with the pg14

13.2.1+33.0.7-fpm with the pg17

Almost. Nextcloud V33 and PG17 are major releases so the recipe version should also follow that:

13.2.0+32-fpm for latest v32 with pg14; I think this recipe version should classify as a minor because 32-fpm makes this a less predictable release.
14.0.0+33.0.7-fpm with pg14
15.0.0+33.0.7-fpm with pg17

> I'm really scared of bug reports from the tag `13.1.5+32.0.13-fpm` pointing to another version... Also, if you do `abra app ls -S`, you can see the versions, but with the variables, you're not sure anymore what the versions are! I'm not so scared of bug reports, but the visibility of what's running is a good point. Let's stick to a use latest release. > So you propose to create a: > > - 13.2.0+33.0.7-fpm with the pg14 > - 13.2.1+33.0.7-fpm with the pg17 Almost. Nextcloud V33 and PG17 are major releases so the [recipe version](https://docs.coopcloud.tech/maintainers/handbook/#how-are-recipes-versioned) should also follow that: - 13.2.0+32-fpm for latest v32 with pg14; I think this recipe version should classify as a minor because 32-fpm makes this a less predictable release. - 14.0.0+33.0.7-fpm with pg14 - 15.0.0+33.0.7-fpm with pg17

ineiti commented

2026-08-06 11:58:48 +00:00

Almost. Nextcloud V33 and PG17 are major releases so the recipe version should also follow that:

Oups - bad copy/paste in my head. Of course!

13.2.0+32-fpm for latest v32 with pg14; I think this recipe version should classify as a minor because 32-fpm makes this a less predictable release.

14.0.0+33.0.7-fpm with pg14

15.0.0+33.0.7-fpm with pg17

(probably) last question: is it 15.0.0 for pg17, or 14.1.0? I'd tend to use the latter, and only increase the major version of the recipe for new major versions of the package itself.

From the handbook:

major: new features/bug fixes, backwards incompatible (e.g 1.0.0 -> 2.0.0).
      the upgrade won't work without some preparation work and others need
      to take care when performing it. "it could go wrong".
minor: new features/bug fixes, backwards compatible (e.g. 0.1.0 -> 0.2.0).
the upgrade should Just Work and there are no breaking changes in
the app and the recipe config. "it should go fine".

so it's probably not backwards compatible and we should use the major? Or how do you interpret this?

> Almost. Nextcloud V33 and PG17 are major releases so the [recipe version](https://docs.coopcloud.tech/maintainers/handbook/#how-are-recipes-versioned) should also follow that: Oups - bad copy/paste in my head. Of course! > - 13.2.0+32-fpm for latest v32 with pg14; I think this recipe version should classify as a minor because 32-fpm makes this a less predictable release. > - 14.0.0+33.0.7-fpm with pg14 > - 15.0.0+33.0.7-fpm with pg17 (probably) last question: is it 15.0.0 for pg17, or 14.1.0? I'd tend to use the latter, and only increase the major version of the recipe for new major versions of the package itself. From the handbook: > major: new features/bug fixes, backwards incompatible (e.g 1.0.0 -> 2.0.0). > the upgrade won't work without some preparation work and others need > to take care when performing it. "it could go wrong". > > minor: new features/bug fixes, backwards compatible (e.g. 0.1.0 -> 0.2.0). > the upgrade should Just Work and there are no breaking changes in > the app and the recipe config. "it should go fine". so it's probably not backwards compatible and we should use the major? Or how do you interpret this?

dannygroenewegen commented

2026-08-06 12:13:01 +00:00

(probably) last question: is it 15.0.0 for pg17, or 14.1.0? I'd tend to use the latter, and only increase the major version of the recipe for new major versions of the package itself.

Yes, 14.1.0 for pg17 is maybe better. Agree to take the perspective of Nextcloud here. Upgrading pg14 to pg17 works fine with pgautoupgrade, so this can be a minor recipe update. But pg18 has a change in the data volume mount path, so that might need a major recipe version if that's indeed a harder pgupgrade.

> (probably) last question: is it 15.0.0 for pg17, or 14.1.0? I'd tend to use the latter, and only increase the major version of the recipe for new major versions of the package itself. Yes, 14.1.0 for pg17 is maybe better. Agree to take the perspective of Nextcloud here. Upgrading pg14 to pg17 works fine with pgautoupgrade, so this can be a minor recipe update. But pg18 has a change in the data volume mount path, so that might need a major recipe version if that's indeed a harder pgupgrade.

👍 1

ineiti commented

2026-08-08 09:28:29 +00:00

Let's continue the discussion in #102 and keep this around for a 15.2.0 or so.

renovate-bot added 1 commit 2026-08-13 11:32:38 +00:00

chore(deps): update pgautoupgrade/pgautoupgrade docker tag to v18 75fa0f6c50

renovate-bot force-pushed renovate/pgautoupgrade-pgautoupgrade-18.x from d5e0064c74 to 75fa0f6c50

2026-08-13 11:32:38 +00:00

Compare

You are not authorized to merge this pull request.

This pull request can be merged automatically.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin renovate/pgautoupgrade-pgautoupgrade-18.x:renovate/pgautoupgrade-pgautoupgrade-18.x

git checkout renovate/pgautoupgrade-pgautoupgrade-18.x

Sign in to join this conversation.

5 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#85