feat(ci): add docker image builds per PR

[vpavlin]

Description

This PR adds a separate Dockerfile which creates an image from a binary built in CI.

It also adds a job which pushes it to a Docker repository (quay.io/wakuorg/nwaku-pr) separate from the one where standard releases are pushed (to keep the latter clean of these "ephemeral" images) - the PR images are cleaned up after 7 days.

Additional step comments the PR to present the newly created image to contributor and reviewers.

You can see the example here: nwaku-test-org#12

There is one caveat - to get the image served as quickly as possible, there is an extra wakunode2 build running, this is not ideal, but it would increase "interactivity" of the PR. It is also easy to just "append" these 2 steps to existing build job if that is preferred - interested in thoughts.

Another option would be to split the build job and first build wakunode2 and the image and then the rest of the binaries (other apps and tools), which are not used any further anyway.

Changes

• additional Dockerfile under docker/binaries/ (following nimbus folder structure here)
• additional job to build wakunode2, build the container image, push it to registry and provide comment

Issue

related to #1877

[jm-clius]

LGTM and this adds a valuable extra layer of CI. Wondering though if we shouldn't start adding short description of each CI job and their purpose in our README?

to get the image served as quickly as possible, there is an extra wakunode2 build running

Mmm. I don't see this as a major issue, at least for now. Assuming we'll often see both failing, which is a bit of wasted effort, but at least we test the docker image building process from start to finish.

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:1881

[vpavlin]

Ha! It actually works!

[Ivansete-status]

Thanks for that! This is awesome!

Is it possible to use the existing Dockerfile? I have the impression that we are adding extra complexity :)

[Ivansete-status]

Shall we add a comment at the top indicating the expected purpose of this Dockerfile?

[vpavlin]

I can add a comment there - something like "A Dockerfile to build a distributable container image from pre-existing binaries" ??

[Ivansete-status]

Yes that sounds great!

[Ivansete-status]

I never realized that but maybe we should avoid mentioning "Whisper client" :)

[vpavlin]

Yeah, I was thinking about that, but kept it to match our current Dockefile:D

[vpavlin]

Is it possible to use the existing Dockerfile? I have the impression that we are adding extra complexity :)

We could, but I would like to gradually move away from rebuilding the binary in the docker build and rather just import some existing binary. We will still use Docker to build the binaries, but the goal is "build once, distribute in many ways". This is a first step where we introduce (and test) a Dockerfile which can take an existing binary and only use the Docker build as a way to produce a distributable package.

Hope it makes sense:)

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:1881

[Ivansete-status]

Is it possible to use the existing Dockerfile? I have the impression that we are adding extra complexity :)

We could, but I would like to gradually move away from rebuilding the binary in the docker build and rather just import some existing binary. We will still use Docker to build the binaries, but the goal is "build once, distribute in many ways". This is a first step where we introduce (and test) a Dockerfile which can take an existing binary and only use the Docker build as a way to produce a distributable package.

Hope it makes sense:)

Lovely, thanks for the answer!