fix(build): make dev builds identical to release builds

[swiatekm]

Make the dev images identical to release images. We can add debug images containing additional tooling separately, but the dev images should just have a different binary, and be otherwise the same as the release ones.

This also fixes an issue where the dev Dockerfile uses the official Go image as the base for the final stage, and copies journalctl and dependencies from a debian image. This is consistent with the production image, but that uses scratch, while the golang image also uses Debian as base. As a result, if the debian versions diverge, it's possible to get cryptic errors about glibc versions, as has recently happened in our CI. See for example https://github.com/SumoLogic/sumologic-otel-collector/actions/runs/5355217286/jobs/9713524369.

[sumo-drosiek]

With that, we are going to introduce the following differences between dev and prod images:

• different journalctl binary
• different process of building docker image

Are we fine with it?

[swiatekm]

With that, we are going to introduce the following differences between dev and prod images:

* different `journalctl` binary

* different process of building docker image

Are we fine with it?

I don't think it's that big a deal, but if we want to stay with the current setup, we should probably use a Debian image and manually install Go instead of using the Go image directly.

Why do we even want the dev image to be different from the prod one? Additional tooling? In that case it should be named differently (debug), and we should publish it for prod as well. WDYT?

[sumo-drosiek]

Why do we even want the dev image to be different from the prod one? Additional tooling? In that case it should be named differently (debug), and we should publish it for prod as well. WDYT?

Not sure. I would expect prod image to build. Dev-builds should be as close as possible to production ones. I don;t think it is debug image, and debug images are different topic

[sumo-drosiek]

Does it work as expected 😮 ?

[swiatekm]

No, but it's pretty close. I set REPO_URL to OPENSOURCE_REPO_URL by default, and then used the former in the release targets.

[sumo-drosiek]

so it works as

build-container-multiplatform-dev: REPO_URL="$(OPENSOURCE_REPO_URL)" build-container-multiplatform

?

[swiatekm]

Works more or less like:

build-container-multiplatform-dev:  
  make build-container-multiplatform REPO_URL="$(OPENSOURCE_REPO_URL)"

except it doesn't start a new shell, and you can do more stuff in the variable assignment.