Add custom labels in build request with conda and spack packges

[munishchouhan]

This PR will add labels in the build request, which will be added in dockerfile for conda and spack packges

[munishchouhan]

kaniko supports this functionality, so i have added directly in its command
https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#flag---label

[pditommaso]

I was assuming the labels to be added to the Containerfile. My understanding this approach only works for kaniko based builds. What about Singularity?

[munishchouhan]

I was assuming the labels to be added to the Containerfile. My understanding this approach only works for kaniko based builds. What about Singularity?

I wasn't aware about singularity, I will add labels in singularity builds also

[munishchouhan]

dockerfile tested with new changes:

munish.chouhan@Munishs-MacBook-Pro wave-cli % ./app/build/native/nativeCompile/wave -f Dockerfile --wave-endpoint https://52cfbbd2458d.ngrok.app --label key=value --label "key2"="value2"
52cfbbd2458d.ngrok.app/wt/83b2a5a52f7a/hrma017/dev:df3ae06b3bcfaac7
munish.chouhan@Munishs-MacBook-Pro wave-cli % docker pull 52cfbbd2458d.ngrok.app/wt/83b2a5a52f7a/hrma017/dev:df3ae06b3bcfaac7
df3ae06b3bcfaac7: Pulling from wt/83b2a5a52f7a/hrma017/dev
8a1e25ce7c4f: Already exists 
8ab039a68e51: Already exists 
2b12a49dcfb9: Already exists 
cdf9868f47ac: Already exists 
e73ea5d3136b: Already exists 
890ad32c613f: Already exists 
4f4fb700ef54: Already exists 
ba517b76f92b: Already exists 
Digest: sha256:d7f86ac439c83467d5758c7257145ef58c472da8faa7e00dd5262f8c5fcbcffd
Status: Downloaded newer image for 52cfbbd2458d.ngrok.app/wt/83b2a5a52f7a/hrma017/dev:df3ae06b3bcfaac7
52cfbbd2458d.ngrok.app/wt/83b2a5a52f7a/hrma017/dev:df3ae06b3bcfaac7
munish.chouhan@Munishs-MacBook-Pro wave-cli % docker inspect 52cfbbd2458d.ngrok.app/wt/83b2a5a52f7a/hrma017/dev:df3ae06b3bcfaac7 --format '{{ index .Config.Labels }}'
map[key:value key2:value2]

[munishchouhan]

tested using singularity

munish.chouhan@Munishs-MacBook-Pro wave-cli % ./app/build/native/nativeCompile/wave  -s --conda-package pandas --wave-endpoint https://f3fa87c34f08.ngrok.app --label key=value --label "key2"="value2"  --freeze --build-repo docker.io/hrma017/dev  --tower-token "eyJ0aWQiOiAyfS5jNDk0MjhlNjAwNWViMzI2OGRmZGM0Mjg5MzlmYzI5M2ZjNTFmZDQz"  --tower-endpoint http://localhost:8008/api --platform linux/arm64

oras://docker.io/hrma017/dev:pandas--fe9c7ef51f3bc73f
munish.chouhan@Munishs-MacBook-Pro wave-cli % docker run  --rm -v /tmp:/opt  quay.io/singularity/singularity:v3.11.4-slim-arm64 pull /opt/image.sif  oras://docker.io/hrma017/dev:pandas--fe9c7ef51f3bc73f
INFO:    Downloading oras image
munish.chouhan@Munishs-MacBook-Pro wave-cli % docker run  --rm -v /tmp:/opt  quay.io/singularity/singularity:v3.11.4-slim-arm64 inspect /opt/image.sif    
key: value
key2: value2
org.label-schema.build-arch: arm64
org.label-schema.build-date: Wednesday_13_March_2024_20:35:44_UTC
org.label-schema.schema-version: 1.0
org.label-schema.usage.singularity.deffile.bootstrap: docker
org.label-schema.usage.singularity.deffile.from: mambaorg/micromamba:1.5.5
org.label-schema.usage.singularity.version: 3.11.4
org.opencontainers.image.created: 2023-12-22T06:51:19.576Z
org.opencontainers.image.description: Rapid builds of small Conda-based containers using micromamba.
org.opencontainers.image.licenses: Apache-2.0
org.opencontainers.image.revision: bbc3ef3862d3f4568d55706dbe6e8129f88f6325
org.opencontainers.image.source: https://github.com/mamba-org/micromamba-docker
org.opencontainers.image.title: micromamba-docker
org.opencontainers.image.url: https://github.com/mamba-org/micromamba-docker
org.opencontainers.image.version: latest

[marcodelapierre]

See comments - thank you Munish

[marcodelapierre]

@munishchouhan @pditommaso by further inspection, I actually think the implementation here in the Wave service could be made to closely match that for other properties in Wave API's ContainerConfig, such as env and entrypoint. env is of particularly good inspiration, considering it is modelled as a List<String>, same as my proposed edit in Libseqera for labels.

I suggest you have a look at how containerConfig.env is handled across the Wave codebase, and go after that for the labels.

What do you think?

[munishchouhan]

@munishchouhan @pditommaso by further inspection, I actually think the implementation here in the Wave service could be made to closely match that for other properties in Wave API's ContainerConfig, such as env and entrypoint. env is of particularly good inspiration, considering it is modelled as a List<String>, same as my proposed edit in Libseqera for labels.

I suggest you have a look at how containerConfig.env is handled across the Wave codebase, and go after that for the labels.

What do you think?

Docker container config requires labels as Map, So now it is getting built-in container augmentation.
I have tested it for singularity and docker and its working

[marcodelapierre]

CI requires merge and release on Libseqera side: seqeralabs/libseqera#18

[pditommaso]

Closing as Spack support will not be maintained anymore

[munishchouhan]

This PR is not related to Spack specifically, this is to add labels in the wave generated containers, so its still valid for conda

[pditommaso]

I think we need to rethink the general strategy for labels. So far, it has been implemented adding labels to the dockerfile, however this will create a different container checksum when adding a label.

Ideally, metadata changes shouldn't alter the container checksum. should be explored the ability to propagate tags via Buildkit APIs