feat: Multi-platform rippled image

[legleux]

High Level Overview of Change

Builds and pushes rippled multi-platform Docker images to GHCR.

Context of Change

We need to start building and testing canonical multi-platform images ASAP.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Future Tasks

• Use CMake configure_file() such that the bare minimum build of rippled gets populated to the BUILD.md document and the Dockerfile so there is only one place to update it.

• Build and push the voidstar images from here so any feature/branch can easily be tested.

• These images should also be tagged by the release version so this will need to be manually updated until that procedure is integrated into CI workflows but for now this will be good for develop images.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.5%. Comparing base (3fb6acd) to head (4014f70).
⚠️ Report is 10 commits behind head on develop.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #6049     +/-   ##
=========================================
- Coverage     78.6%   78.5%   -0.0%     
=========================================
  Files          817     818      +1     
  Lines        68976   68981      +5     
  Branches      8242    8265     +23     
=========================================
- Hits         54196   54170     -26     
- Misses       14780   14811     +31     

see 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mathbunnyru]

Instead of doing all of the above, let's make build-image depend on the build, add needed targets to the matrix, and needed artifacts and in reusable-build-image.yml just download these artifacts and here put them in the right place

The reason is that when you build in 2 different places, you actually end up with 2 different binaries, and we want to avoid this

[legleux]

and we want to avoid this

Why do we want to avoid this?

@bthomee Suggested building the CI built binary into the image while also providing a Dockerfile with the build but I'd rather image the binary than have 2 Dockerfiles.

Let's go even further with a multi-stage image build where we have a container action obtain/build the dependencies and another that builds rippled (and why not, another to install it.) Something like that would actually address all of our concerns, be extremely explicit and copy-paste-able for anyone to use. That's for another day.

This does the thing it purports to do today and is needed yesterday.

[ckeshava]

Hello, this is Keshava from the DGE team. We use the ripple docker images in our integration test pipelines for the client libraries.

Personally, I find it more readable if I can find the HEAD commit associated with a docker build. Recently, we have had to investigate several CI failures in the client libraries CI runners due to updates to the amendments' status.

Instead of doing all of the above, let's make build-image depend on the build, add needed targets to the matrix

I feel adding the workflow dependency makes it harder to associate the docker image with a commit-hash, given that the dependency graph is large for the rippled build process.

Let's go even further with a multi-stage image build where we have a container action obtain/build the dependencies and another that builds rippled

Something like this is definitely more informative ^^ For example, if I can see what amendments were retired/enabled/removed in a rippled-docker image, that will save me a lot of time.

[mathbunnyru]

I feel adding the workflow dependency makes it harder to associate the docker image with a commit-hash, given that the dependency graph is large for the rippled build process.

No matter how you build rippled for the docker image, we should always tag the resulting image with the hash of the commit.
It's a well established practice, both in Clio's CI images, and in rippled's CI images.
And, no matter if the dependency graph is large or not, you'll be able to use such a tag, so it will be obvious which commit the docker image was built from

[mathbunnyru]

Why do we want to avoid this?

Let me explain, why I think we should deal with artifacts, and not build everything inside docker image:

• it's what Clio does
• you won't have one more place where you build rippled
• if there are some changes in the build pipeline which affect the binary, you will only have 1 place to make the change (for example if we pass some additional variables to cmake), in your implementation it's easy to forget to update the Dockerfile
• Dockerfile will be so simple - COPY with a few tweaks
• you will put a tested binary in Dockerfile
• there will be no need to use complicated setup for building multi-arch workflow, you'll be able to build multi-arch image directly

[mathbunnyru]

It's quite a long piece of code, let's make it a script?

[legleux]

This step uses output from the docker/metadata-action@v5 step is tightly coupled to this implementation. What utility would a separate script provide?

It could be generalized and not use docker/metadata-action@v5 and it was previously done like this but this is here now and how all of the other workflows we've written in GitHub work.

[mathbunnyru]

Putting a huge piece of code is beneficial due to following reasons:

• better syntax highlighting in editors
• tooling will run better for scripts
• they can be reused
• they make you think better of what the input is and output is
• no quirks due to have yml syntax interacts with bash syntax