Allow erlang/otp release to trigger images' build flow

[paulo-ferraz-oliveira]

Motivation

To automate Erlang/OTP release -based Docker image building next to erlang/docker-erlang-otp (these days I understand it's a manual process), originating from erlang/otp.

Ref: https://github.com/erlang/otp/pull/7813

Description

As per what's been recently discussed in the #build-and-packaging EEF Slack channel, and since erlang/otp accepts triggering builds next to erlang/docker-erlang-otp, I'm pushing this to make that happen.

I attempted (and tested in that sense) to have a completely isolated flow that stimulates the other existing one (erlang.yaml).

erlang/otp, after release, will dispatch this new workflow (with and OTP version and SHA256 checksum string), which will:

1. update the Dockerfile for the base image and variants slim and alpine
2. create a pull request, and merge it (deleting the created branch)
3. trigger (via dispatch, already supported) erlang.yml

(⚠️ is this the expected follow up? I don't actually see any place where the images are pushed from GitHub, only built and tested)

Full automation

I can imagine concerns around this "full automation", but I can also e.g. remove some of the steps (e.g. after pull request creation do nothing else) for us to gain confidence in the process. On the other hand if, at the end of erlang.yml we include a step to upload the images this'd be full automation 😄.

Authentication

In my tests, I used a custom GitHub App I created for that purpose, but I'm not sure how you intend to do integration between these two repositories. Lemme know what changes I should discuss/require next to erlang/otp.

Further considerations

Something very similar (albeit maybe more complicated, because it'd require more rules) can be done for rebar3's integration in the images.

I left some # Requires comments in the workflow that I might take out once I understand the general direction for this.

[paulo-ferraz-oliveira]

Hi, @getong. Do you think this pr will get any attention? Thanks.

[getong]

I have no idea of this pr. @tsloughter What do you think about this ?

[csrl]

Looking forward to 26.2.3 release, if this automation was in place, it would already be available.

[paulo-ferraz-oliveira]

Unfortunately it's taking some time. And after this, for the automation to be "complete", there's the other erlang/otp pull request that needs to be reviewed and/or tweaked.

[paulo-ferraz-oliveira]

👋 Can I do something to help move this forward?

[paulo-ferraz-oliveira]

@tsloughter 😄

[tsloughter]

I wouldn't merge the PR automatically. As long as the only action needed is to merge the PR I think that should be the first step.

Other than that, I love it. Sorry I somehow never noticed this PR before... :)

Also note @paulo-ferraz-oliveira I believe the flow is that the images are built elsewhere since they are official images.

[paulo-ferraz-oliveira]

Sure, the only thing I'm trying to do, with this, is speed up the review+merge process. 😄

The end goal is:

1. Erlang/OTP gets built and released and then they call this repo.
2. this repo. handles the call by creating a pull request that gets tested
3. when that's done we can approve/merge

... so the release time is theoretically lower.

I reviewed what I wrote (it's been a year) and I could remove the code I've now identified above (for removal, or maybe comment if we want to add it in the future).

We'd just be doing:

1. update the Dockerfile for the base image and variants slim and alpine
2. create a pull request

(without the "full automation" part - or even the creation of the files via pull request approval)

You'd also need to tweak the repositories' settings, as per the comments in the updated file, and create a GitHub App to have CI run when the PR is created.

If that's possible, for you, I can follow this up...

[paulo-ferraz-oliveira]

I'm closing, for the moment, since it is not getting traction. If the need is discussed again, we at least have an example implementation.