Allow erlang/otp release to trigger images' build flow #454
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi, @getong. Do you think this pr will get any attention? Thanks. |
|
I have no idea of this pr. |
|
👋 |
|
Looking forward to 26.2.3 release, if this automation was in place, it would already be available. |
|
Unfortunately it's taking some time. And after this, for the automation to be "complete", there's the other |
|
👋 Can I do something to help move this forward? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 fromerlang/otp.Ref: erlang/otp#7813
Description
As per what's been recently discussed in the #build-and-packaging EEF Slack channel, and since
erlang/otpaccepts triggering builds next toerlang/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:Dockerfilefor the base image and variantsslimandalpineerlang.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.ymlwe 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
# Requirescomments in the workflow that I might take out once I understand the general direction for this.