Add digests of the images being used for examples

[tetsuok]

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

In testing/examples, running bazel test //... yields the following warnings that digests of the images being used are not specified:

DEBUG: Rule 'ubuntu1604' indicated that a canonical reproducible form can be obtained by modifying arguments digest = "sha256:8f0b64fd212007183434b8b3271b723700ab14e4230b5bec1415b79aaa3ac97b"
DEBUG: Repository ubuntu1604 instantiated at:
  /home/t/rules_docker/testing/examples/WORKSPACE:51:15: in <toplevel>
Repository rule container_pull defined at:
  /home/t/.cache/bazel/_bazel_t/8f44971fccf59391c1b86a62b75f492c/external/io_bazel_rules_docker/container/pull.bzl:270:33: in <toplevel>
DEBUG: Rule 'bazel_image' indicated that a canonical reproducible form can be obtained by modifying arguments digest = "sha256:ace9881e6e9c5d48b5fd637321361aeffe54000265894a65f7d818dc1065bd80"
DEBUG: Repository bazel_image instantiated at:
  /home/t/rules_docker/testing/examples/WORKSPACE:58:15: in <toplevel>
Repository rule container_pull defined at:
  /home/t/.cache/bazel/_bazel_t/8f44971fccf59391c1b86a62b75f492c/external/io_bazel_rules_docker/container/pull.bzl:270:33: in <toplevel>
DEBUG: Rule 'alpine_linux_amd64' indicated that a canonical reproducible form can be obtained by modifying arguments digest = "sha256:954b378c375d852eb3c63ab88978f640b4348b01c1b3456a024a81536dafbbf4"
DEBUG: Repository alpine_linux_amd64 instantiated at:
  /home/t/rules_docker/testing/examples/WORKSPACE:44:15: in <toplevel>
Repository rule container_pull defined at:
  /home/t/.cache/bazel/_bazel_t/8f44971fccf59391c1b86a62b75f492c/external/io_bazel_rules_docker/container/pull.bzl:270:33: in <toplevel>

Issue Number: N/A

What is the new behavior?

Specifies the digests suggested by the warnings.

Does this PR introduce a breaking change?

• Yes
• No

Other information

[alexeagle]

@gregmagolan this looks like a chance for us to document that surprising behavior that the tag is ignored if a digest is present, do I have that right?

[uhthomas]

It's documented as part of the tag attribute for container_pull.

[alexeagle]

could you just add a comment on the tag field that it is now ignored, and only useful as documentation?
Might help some user who is following the example, as this is a serious footgun.

(we had a client update the tag, probably thinking they picked up a security fix, and did not realize that it's a no-op. IMO we should actually error in this case instead.)

[tetsuok]

@alexeagle Just want to confirm the above comment is for me?

[alexeagle]

yes please, I'd rather not introduce digests into the example unless we warn users about that

[gregmagolan]

I believe @alexeagle is referring to commenting in the BUILD file as the current behaviour is suprising:

    name = "alpine_linux_amd64",
    digest = "sha256:954b378c375d852eb3c63ab88978f640b4348b01c1b3456a024a81536dafbbf4",
    registry = "index.docker.io",
    repository = "library/alpine",
    # tag field is ignored since digest is set
    tag = "3.8",

I also think it should be an error if you specify both since it is too easy to update the tag and think that your change is load bearing

[alexeagle]

I was imagining that we should error when you provide both digest and tag since the latter is ignored, but @gravypod points out that bazel's git_repository does the same. I guess we could warn but it's not actionable. We could document and recommend the separate dictionary scheme that @gregmagolan did for a client. WDYT?

To merge this PR I'm happy with any comment on the tag field so users are aware.

[alexeagle]

Thanks!