Improve Renovate configuration

[andyundso]

This PR should solve a couple of issues with our Renovate configuration.

• Use Homebrew as the source for the different Postgres version. Macports still did not update all their versions, and Homebrew has done it basically on release day for the new PG versions.
• Track the alpine version in the Dockerfile to ensure that we also use the Alpine version for the final Docker images.
• Similarly, track the alpine version in the GitHub Actions file to ensure the tag will be correct.

I tested the changes on my personal fork of the repository, looks like it does what it should:

• Dependency Dashboard andyundso/docker-pgautoupgrade#3
• Update alpine Docker tag to v3.21 andyundso/docker-pgautoupgrade#10

[wuast94]

maybe, if we would like to be up to date to the base image, we should pin the digest? that would be something we could automerge

[andyundso]

@wuast94 do you have an idea on how we would pin the digest with our current Dockerfile setup? Right now a lot depends on the PGTARGET build variable. we would need to pin the digest for each of our target versions (PG v12 to v17) and then somehow switch based on the PGTARGET variable? or add multiple Dockerfile, one for each version, but this would be a lot of code duplication.

[wuast94]

Here we could enable pinning without a problem.

docker-pgautoupgrade/Dockerfile.alpine

Line 4 in 0c38e35

FROM alpine:3.20 AS base-build

never worked with repology and i dont know if the datasource and/or renovate can pin digests there

but it only makes sense if an image or package changes without changing the tag or version. for example in docker if a container only have a latest tag that will be updated then pinning makes sense to make sure to grab that specific release. otherwise some caching etc could use an older image than available. also i use it in my swarm cluster to keep non versioned containers up to date, but thats another use of pinning digests there.

i looked a bit at the sources and i dont think that we really need pinning at all here?

[andyundso]

I imagine that alpine:3.21 as well as all the postgres:<some version>-alpine3.21 get pushed frequently with sometimes new content. However, I do not think we need to pin the digest - buildx does recognize when base layers changed compared to previous images and should re-pull in most cases. Even if we are behind a couple of pushes, I don't think that's too bad. Important is that we stay up-to-date with the Postgres versions themselves.

[justinclift]

Even if we are behind a couple of pushes, I don't think that's too bad. Important is that we stay up-to-date with the Postgres versions themselves.

Yeah, that sounds like the right prioritisation to me too. At least, it sounds like the right thing to start with. 😄

We can adjust that in future if it turns out to be needed, etc.