Due to differences in the rules, the build targets in //docker have slightly changed behaviour:
//docker:<component> is an unpacked oci layer that can be packed into other layers.
//docker:<component>.tarball is the target producing the docker image .tar
//docker:<component>.load is a runnable target to load the tarball into docker
The distinction between .tar and .load is due to a weird behavior of bazel related to targets that are both runnable and return files ($(location ..) does not seem to work properly, see comment in docker/scion_apps.bzl, in scion_app_image()).
//docker:prod and //docker:test are no longer runnable, they are just a filegroups of the tarballs. The runnable target could previously be used to load all images. This would now require an additional external rule (multirun) which seems unnecessary (loading images is trivial).
//docker:gateway creates a plain binary without setcap.
This simplifies the build process; it avoids having to install setcap tools which would be more complicated now with rules_oci/rules_debian_packages.
//docker:tester is now built with rules_debian_packages (instead of the no longer compatible rules_deb_packages).
Introduce consistent naming and tagging of all produced docker images. All images are now tagged scion/<component>:latest. For router and gateway, the names were simplified by dropping the posix- prefix.
For internal images used for testing we use nested names e.g. scion/tools/udpproxy or scion/acceptance/topo_reload_cs.
Furthermore, all images are annotated with a docker label org.scion (no value). This allows cleaning up with a relatively simple match, as is now done in make clean. Additionally, the label org.scion.version will be set when building with --stamp.
The motivation to be able to clean up is to have a simple way to ensure that tests actually pick up the intended images; I managed to thoroughly confuse myself by building new images with a misspelled name, causing old images to be picked up unnoticedly.
I looked for different options to make this even stricter, but alternatives seemed either heavy handed (start a separate docker daemon, or temporarily rename all existing images), or toothless (e.g. use a randomized tag :test-xxx for all images, which can be bypassed by tests too easily).
More details:
simplified acceptance test infrastructure: --container-loader=<tag>#<path-to-shellscript-loading-a-docker-image> is now just --docker-image=<path-to-tar>. The naming is assumed to be consistent, no docker tag is done anymore (see discussion above).
acceptance/sig_short_exp_time, which is broken #3935: update the setup so it keeps running until the known failure. Instead of building various helper images, which is now rather verbose with rules_oci, use the "stock" images and mount the necessary config as volumes.
acceptance/topo_daemon_reload and topo_cs_reload: add cleanup so that helper images are removed after test
Recommendation: remove any old scion-y images.
# enable commented section after double checking that these images are safe to remove
docker image ls --format '{{.ID}}\t{{.Repository}}:{{.Tag}}' | grep -E 'scion|dispatcher|daemon|control|tester|udpproxy|posix.router|posix.gateway|bazel\/' # | cut -f 1 | xargs docker image rm
matzf
commented
3 months ago 
rules_docker is no longer maintained and causes issues with particular versions of docker (see e.g. https://github.com/scionproto/scion/issues/4480). Replace our use of rules_docker by https://github.com/bazel-contrib/rules_oci.
Due to differences in the rules, the build targets in
//dockerhave slightly changed behaviour://docker:<component>is an unpacked oci layer that can be packed into other layers.//docker:<component>.tarballis the target producing the docker image .tar//docker:<component>.loadis a runnable target to load the tarball into docker The distinction between.tarand.loadis due to a weird behavior of bazel related to targets that are both runnable and return files ($(location ..)does not seem to work properly, see comment indocker/scion_apps.bzl, inscion_app_image()).//docker:prodand//docker:testare no longer runnable, they are just a filegroups of the tarballs. The runnable target could previously be used to load all images. This would now require an additional external rule (multirun) which seems unnecessary (loading images is trivial).//docker:gatewaycreates a plain binary without setcap. This simplifies the build process; it avoids having to install setcap tools which would be more complicated now with rules_oci/rules_debian_packages.//docker:testeris now built with rules_debian_packages (instead of the no longer compatible rules_deb_packages).Introduce consistent naming and tagging of all produced docker images. All images are now tagged
scion/<component>:latest. For router and gateway, the names were simplified by dropping theposix-prefix. For internal images used for testing we use nested names e.g.scion/tools/udpproxyorscion/acceptance/topo_reload_cs. Furthermore, all images are annotated with a docker labelorg.scion(no value). This allows cleaning up with a relatively simple match, as is now done inmake clean. Additionally, the labelorg.scion.versionwill be set when building with--stamp. The motivation to be able to clean up is to have a simple way to ensure that tests actually pick up the intended images; I managed to thoroughly confuse myself by building new images with a misspelled name, causing old images to be picked up unnoticedly. I looked for different options to make this even stricter, but alternatives seemed either heavy handed (start a separate docker daemon, or temporarily rename all existing images), or toothless (e.g. use a randomized tag:test-xxxfor all images, which can be bypassed by tests too easily).More details:
--container-loader=<tag>#<path-to-shellscript-loading-a-docker-image>is now just--docker-image=<path-to-tar>. The naming is assumed to be consistent, nodocker tagis done anymore (see discussion above).Recommendation: remove any old scion-y images.
Closes #4481