Build, test and deploy from GitHub Actions

[andyundso]

Replaces #19.

This PR contains a GitHub Actions configuration that can build a multi-arch version of the pgautoupgrade container. In a nutshell:

• To optimise resources, each version of Postgres from which an upgrade should be possible gets its own build job. Generally, the ARM build is done with QEMU, so compile-times of 25 minutes are usual. So the previous sequential approach did not scale. Subsequent runs of this build step should be cached.
• Then each final version (v12 to v16) gets build, tested and pushed (if main).

[andyundso]

we could let the workflow run every week automatically to produce updated images (e.g. if Alpine updates).

[justinclift]

Cool, that sounds like a good idea. I'd been wondering how other projects handle that. 😄

[andyundso]

addressed with 012887f.

[wuast94]

Cool, that sounds like a good idea. I'd been wondering how other projects handle that. 😄

with daily builds. to keep the base system up to date you have to build the container every day/week with updates in the dockerfile

[justinclift]

Cool. Sounds like we just need to set up some scheduler somewhere and then mostly forget about it. 😄

[andyundso]

@justinclift I think this is ready for review / merge.

one thing I noted is that the new ARM64 build is untested. but maybe we can do another PR in the (near) future which runs the tests on a ARM64 runner.

[wuast94]

we should add some type of versioning to this.

i for example deploy this in a swarm cluster and run renovate against my repo to check for updates, that way i can monitor for updates and check if there are breaking changes.
i would suggest something like {semver}-{pg_version}+{build} = 1.2.3-pg16+20230315 when using daily builds

[justinclift]

Wonder if we'll run into storage space problems with Docker Hub if we do that?

I'm guessing there's some limit to how much they'll let (free) users store.

Oh, the application I submitted to convert the Docker Hub repo to be "OSS Sponsored" never got a response.

I guess since we don't have a million downloads already we're too small or something. That's just a total guess though, could be totally wrong.

[wuast94]

as far as i can see is that the only limit a free account has is the pull rate limit and the number of private repos.

and i know other projects that have lots of daily builds

so i would say that shouldnt be a problem

[justinclift]

Awesome. Sounds like an approach we should try out then. 😄

[andyundso]

I am a bit split for adding tags for daily builds.

On one hand, it is not much effort to implement, simply derive from the current date and adjust the tag. But we also might up with a lot of Docker tags that nobody really uses. Sure, there is not a storage limit, but still seems kind of wasteful.

Then there is the case of us running pushing a new build, maybe there was something in Alpine updated which could break something, but we do not catch with the automated tests. I have been working with containers in software development for the last five years without running any daily tags, and I would say there were only a couple of cases were this happened, compared to the hours we saved by not having to look what version we are now running exactly.

what I would support is adding a version to the script itself, because there I see we most likely implement a breaking feature. You would need to keep the Postgres version in front, otherwise Renovate will never update because v16 of Postgres > v1.0 of the script.

Ultimately, I do not mind if we happen to implement both, it would still be more "security" than there is now in regards to versions and builds.

[justinclift]

one thing I noted is that the new ARM64 build is untested. but maybe we can do another PR in the (near) future which runs the tests on a ARM64 runner.

@andyundso I'll get the self-hosted ARM64 runner back online today. If you want to try running this PR on that you then can, or we can attack that particular part of things in a follow up PR like you're thinking. 😄

[justinclift]

@andyundso The ARM64 build runner is back online and hooked up to GitHub Actions in this repo.

[justinclift]

Needs to be install-world instead of install.

The -world make target also installs commonly used PG extensions (as per this commit).

Thinking about that more, we might not need it for the early PG versions people are migrating away from, but it'll definitely be needed for the "target" PG versions people are upgrading to.

[andyundso]

I adjusted it for all PG versions now, just to keep it consistent, in bad495a.

The build will likely take a while, since it will not be able to use the build images. good test in any case 😅

[justinclift]

This looks really good.

I think the only item that really needs changing is to use install-world for the PG bits rather than install, so the extensions get included.

Everything else (potential versioning, different scheduling, etc.) we can figure out later as we see how this goes. 😄

[justinclift]

Awesome @andyundso. 😄 Merging this now.

The versioning idea that @wuast94 raised seems useful too, but we can figure that out separately from this. 😄