Dynamic container definition

[atteggiani]

Overview

The current container definition gets outdated every time a new environment is released, making it more laborious to maintain and prone to errors similar to this one.

I suggest making the definition dynamic (with env variables to be read at build time and set within the pull_request.yml based on the current version).

This way, the image for each new environment version will always be built with its own environment folder mounted within itself.

Questions

1. Why are other environment versions within the definition of a different environment (i.e., why is the definition the same for all the environments)? Is there ever the use-case to activate an environment version from within an image of a different version environment? (e.g., activating conda/analysis3-25.04 from the conda/analysis3-25.09 image).

2. I see analysis3-25.09 is within the container's /opt/conda even though it's not defined in the current container definition. How can it be there? Was that folder manually created? (I see it has @rbeucher as owner instead of root).