Description
containertool currently adds the app layer to the beginning of the layer stack array in the manifest. This results in the app layer being the first to be unpacked, with the others stacked on top. We can show this by adding a plain text file as the executable. If we stack another layer on top with a file of the same name, it should replace the underlying one but it does not:
echo first > bar
swift run containertool --repository localhost:5555/bar bar
podman run --pull=always -it --rm --entrypoint=cat localhost:5555/bar:latest bar
# prints: first
echo second > bar
swift run containertool --repository localhost:5555/bar bar --from localhost:5555/bar:latest
podman run --pull=always -it --rm --entrypoint=cat localhost:5555/bar:latest bar
# prints: first
# should print: second
Currently containertool is only used to add the application binary to the application layer. This bug will only cause a problem if the base layer adds a binary at the same path, because this will override the application.
This bug probably arose because the specification for the rootfs.diff_ids field of the image configuration defines the layers as being "in order from first to last", which could be read ambiguously: https://github.com/opencontainers/image-spec/blob/main/config.md?plain=1#L220-L222
The specification for the manifest.layers field is much more explicit about the ordering: https://github.com/opencontainers/image-spec/blob/fbb4662eb53b80bd38f7597406cf1211317768f0/manifest.md?plain=1#L70-L71