Please seriously consider having releases

[grepwood]

Hi, I'm using distroless at work and I'm facing a few issues. Having releases would really help out:

1. I'm finding it really frustrating that I have to resolve each git commit sha into dates of publishing in order to tell which git commit sha is newer.
2. In each release, we would be able to attach binaries that have a chicken-and-egg problem in Bazel. This is especially useful for organizations that can't access https://storage.googleapis.com due to strict security policies. GitHub is accessible just fine.

I tried to use the commit where distroless "apparently" compiles the par file for dpkg_parser on its own, but this is an entirely pointless exercise, because that commit is written such that it expects us to download distroless outside of the WORKSPACE of our monorepo, build our stuff there, and then it has some weird hardcoded path to bazel-bin inside of distroless... it's a really messy situation. For me at least, it would be completely resolved if dpkg_parser.par was hosted on GitHub.

And others would probably appreciate easy version numbers to work with :)

[ReillyBrogan]

You're doing it wrong frankly. What you should be doing is doing a docker pull on the latest tag and then get the digest from the downloaded image.

docker pull gcr.io/distroless/base-debian11:latest
docker inspect --format='{{index .RepoDigests 0}}' gcr.io/distroless/base-debian11:latest

This will print the digest of the image, which you then use with your Docker files:

FROM gcr.io/distroless/base-debian11@sha256:73deaaf6a207c1a33850257ba74e0f196bc418636cada9943a03d7abea980d6d

If you mean that you're trying to generate your own distroless images with packages of your own you probably shouldn't be doing that. Instead you should follow the same format as the fluent-bit images where you add the packages your binaries depend on as an additional layer to the base Distroless image (Use repro-get if you want reproducible package versions). Then you can add your binaries as the final step of the image pipeline.

[grepwood]

If you mean that you're trying to generate your own distroless images with packages of your own you probably shouldn't be doing that

And what I am doing, is importing distroless as a http_archive in Bazel, and then importing a known, working copy of the Debian image that Bazel depends on, also in Bazel. Next, I do this in this particular order:

• I define what Debian package index we are working against
• I initialize distroless' dpkg simulacrum to parse this index
• I download a bunch of packages that all of my microservices depend on
• in each microservice BUILD file, I specify which packages to add to a layer that will go on top of the base Debian (from distroless) layer, then I add the files specific to the microservice to make it all work in 1 image, comprised of let's say maybe 3-5 layers tops

All according to https://github.com/GoogleContainerTools/distroless/tree/main/package_manager

Instead you should follow the same format as the fluent-bit images where you add the packages your binaries depend on as an additional layer to the base Distroless image

That's practically the same what I'm doing.

You're doing it wrong frankly

That's offtopic. And I've already demonstrated it's a false assumption. Look. Nothing personal, I'm just saying I feel like what I asked for has not been addressed in the slightest and got a template response instead.

To further drive my point:

I'm finding it really frustrating that I have to resolve each git commit sha into dates of publishing in order to tell which git commit sha is newer.

Here is what my relevant part of WORKSPACE looks like:

http_archive(
    name = "distroless",
    url = "https://organization_mirror_to_github/GoogleContainerTools/distroless/archive/" + magical_commit.sha + ".tar.gz",
    sha256 = magical_commit.tarball.checksum,
    strip_prefix = "distroless-" + magical_commit.sha
)

If I were a machine, I could easily ignore this. Sadly, I am only human, and I find it easier to navigate between let's say

0.2.1
0.2.0
0.1.0

than

5f4db907b8106a9ef00e015af15e84f80e8d7c9a
f4dc1f69dd1c593a991035ea22e6b7e8180f1985
b33d50ba541864d20148782d2908bcaae6c156ad

These sha sums don't even mean anything without any context. They are not immediately indicative which one is newer or older, which is their main disadvantage compared to versions.
If distroless gets versions, then my code could look like this:

http_archive(
    name = "distroless",
    url = "https://organization_mirror_to_github/GoogleContainerTools/distroless/archive/0.2.0.tar.gz",
    sha256 = whatever_sha_that_versions_tarball_has,
    strip_prefix = "distroless-0.2.0"
)

[phlax]

+1 - quoting myself 8/ ...

The ideal for us would be the published image only gets updated when there is a change - or versioned releases are used so we can track them rather than git commits.

#1239