Convert to multi-stage builds

[lukebakken]

Start with the Ubuntu template

Follow-up to #587

[lukebakken]

@tianon I've got some minimal changes in the templates to support multi-stage builds.

I'm not sure what's up with the CI failure, however:

bashbrew version v0.1.5
Processing rabbitmq:3.11.3 ...
failed fetching repo "ubuntu:20.04"
unable to find a manifest named "ubuntu" (in "/tmp/tmp.SIfMOjytit/library" or as a remote URL)
+ strategy=

...I can reproduce the same error locally, but I'm not sure of the source of the error. It seems like generate-stackbrew-library.sh is working correctly.

Note that I had to add the setup-go action to fix a compile error in bashbrew. Apparently go 1.18 is required now? 🤷‍♂️

Assistance is appreciated! I will of course clean up commit history once this is figured out.

[tianon]

Sorry! If you drop your .github changes and rebase on #590, it should be fixed. 🙇

[lukebakken]

This is just about ready for review. I need to figure out why the alpine image is quite a bit larger with these changes in my env:

$ docker images '*rabbit*'

REPOSITORY                                  TAG                        IMAGE ID       CREATED         SIZE
rabbitmq-local-multi-stage                  alpine-latest              fd57cc784e62   2 minutes ago   162MB
rabbitmq                                    3-alpine                   6d8788289676   4 days ago      127MB

rabbitmq-local-multi-stage                  ubuntu-latest              48b7a0359d68   5 hours ago     229MB
rabbitmq                                    3                          792f1c5d392c   6 days ago      229MB

UPDATE: hmm I really have no idea why it's 35mb larger, especially since the ubuntu one is the same size 🤔

[lukebakken]

Within the running containers the sizes are comparable:

# rabbitmq:3-alpine    # alpine multi-stage
bash-5.1# du -hs *     bash-5.1# du -hs *
2.0M    bin            2.0M    bin
0       dev            0       dev
547.0K  etc            675.0K  etc
512     home           512     home
4.2M    lib            4.2M    lib
2.0K    media          2.0K    media
512     mnt            512     mnt
24.5M   opt            24.5M   opt
512     plugins        512     plugins
1.0K    root           1.0K    root
512     run            512     run
160.0K  sbin           171.0K  sbin
512     srv            512     srv
0       sys            0       sys
1.0K    tmp            1.0K    tmp
98.8M   usr            98.3M   usr
108.0K  var            108.0K  var

[lukebakken]

I'm not going to worry too much about the local image size because if I build from master in the 3.11/alpine directory the size is larger than the pulled image 🤷‍♂️

[tianon]

Overall pretty minor comments all around! 👍

I did compare CI builds of yours to recent master CI builds, and the sizes look comparable:

• https://github.com/docker-library/rabbitmq/actions/runs/3483776129/jobs/5827634135#step:8:19 (your 3-alpine, ~126MiB)
• https://github.com/docker-library/rabbitmq/actions/runs/3483672593/jobs/5827423409#step:8:19 (master's 3-alpine, ~128MiB)
• Ubuntu-based builds were similar, yours at ~228MiB, master at ~229MiB

👍

[tianon]

(To be explicit: I think the readonly suggestion is the only one of those I'd make a blocker - everything else is fine as-is if you don't want to change it. 👍)

[lukebakken]

I've always wondered exactly why shellcheck flags that use of readonly, and thanks to your example I understand why now.

[lukebakken]

@tianon thanks for the review. Seems like multiple builds are being generated for the same Docker image?

https://github.com/docker-library/rabbitmq/actions/runs/3500314277

...not sure if that's due to my changes or something in bashbrew

[tianon]

Seems like multiple builds are being generated for the same Docker image?

That's intentional -- note the (i386) at the end. It's doing a 32bit build for images which support it (in our case only Alpine since Ubuntu dropped it) as a rough smoke test for our multiarch support. 👍

[lukebakken]

@tianon I'll resolve the conflicts. Anything else need to be done?

[lukebakken]

Hmm, investigating the latest round of alpine build failures.

[tianon]

Ah, that's probably #592 -- Alpine 3.17 updated the default OpenSSL in the distro to OpenSSL 3, so maybe that's conflicting somehow (I thought we had some mitigations to avoid that but maybe they broke or something)?

[lukebakken]

@tianon ha, no it was much simpler... I didn't update the final base image to alpine:3.17, so there were mismatches in which packages were added for Erlang run-time deps.

It did prompt me to ask this - #596

[lukebakken]

@tianon are we waiting on one more review here? Do you need anything else from me?

[tianon]

Yeah, just waiting for @yosifkit to get some time to go through it again 👍