Show digest of pushed images

[illicitonion]

No description provided.

[zoidyzoidzoid]

This looks good to me.

Rebasing may bump some things to reassign who should approve this, since the owners changed in a4d580e

It'd be great to have tests for some of these binaries, but that's definitely out of scope of this PR.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: illicitonion
To complete the pull request process, please assign after the PR has been reviewed.
You can assign the PR to them by writing /assign in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[alexeagle]

Hi @illicitonion !!

I'm curious what's the motivation for this change? Did you want to copy the digest to paste somewhere? compare the digest with some other reference?

[alexeagle]

nit: in the interest of preserving compatibility, could you make this non-fatal? I don't think there's a case where the digest fails but if it did we can just print the original message

[illicitonion]

Absolutely - done

[illicitonion]

Hi @illicitonion !!

👋 🎉

I'm curious what's the motivation for this change? Did you want to copy the digest to paste somewhere? compare the digest with some other reference?

Yeah, we have deployment manifests which list the sha256 of the docker images that should be deployed, and so with this change we can trivially copy&paste / scrape them from logs to put them in our deployment manifests. Without this change, we need to look externally for information from the container registry, which it's nice to avoid needing to do, given we already know the information here :)

[alexeagle]

Ah, I think you're just looking for the .digest-suffixed output of container_push which gives you exactly that info in a file. Then you don't have to scrape the message either - does that work for you?
https://github.com/bazelbuild/rules_docker/blob/master/container/push.bzl#L217-L219

[illicitonion]

Ah, I think you're just looking for the .digest-suffixed output of container_push which gives you exactly that info in a file. Then you don't have to scrape the message either - does that work for you?
https://github.com/bazelbuild/rules_docker/blob/master/container/push.bzl#L217-L219

I'm currently using https://github.com/bazelbuild/rules_docker/blob/master/contrib/push-all.bzl which doesn't expose this at the moment. I'm currently just running bazel run //some:push-all, and it's not obvious how we'd wire it up to proxy those things through... Any ideas on how we'd go about that?

I guess we'd need to go from one bazel invocation to two, so we could drive building the digest files before/after pushing them?

[github-actions]

This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[github-actions]

This PR was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"

[pcj]

I've also had to resort to extra steps to retrieve the digest myself, so this is a welcome change.

It would be useful IMHO if the printed string was something like Successfully pushed image to us.gcr.io/foo/ubuntu@sha256:digest, because then it can be immediately copy-pasted into a kubernetes yaml or docker pull command.

[pcj]

Approving, but would welcome a slightly different format (see comment above)

[illicitonion]

Edited to be easier to copy and paste - I didn't want to remove the old text because the label substitution may also be relevant, so I had it do both if the stamped label isn't a digest.

[gwuah]

This is a small change that has made my work/life very easy. thanks for this PR @illicitonion