Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: jenkins
-
Labels:None
-
Team:Architecture
-
Urgent?:No
Description
Unfortunately, the DM-23565 fix was insufficient. While it looked good from a code perspective, it appears that the environment file created in run-rebuild is not preserved for the run-publish pipeline. Investigate how state is shared between these pipelines and see whether this environment file can be similarly shared, or else arrange for it to be re-created in run-publish. (This will be made harder by the fact that the state does not appear to be preserved on GPFS but instead is more ephemeral.)
Attachments
Activity
Or write the .env file to the stack directory tree instead of the build directory. (since surely the stack directory must exist)
It is being written to /j/snowflake/release/lsstsw/env, which seems like it should be preserved from rebuild to publish along with the rest of /j/snowflake/release/lsstsw.
Gabriele Comoretto [X] and I would like to remove the conda environment selection from run-rebuild and run-publish, as we think they should always use the default environment. But that is a bit tricky right now, so to get nightlies moving again I have implemented what I hope is a minimal fix, passing the (default) environment hash to the run-publish pipeline and having it be used in the invocation of envconfig instead of the build number.
The change looks good to me.
Not sure how we can test it.
It ran properly for dax/release/rebuild_publish_qserv-dev. I'm re-running nightly-release.
nightly-release has run through the publish step, so I'm closing this.
I think it is safer just to provide the environment reference to run_publish and activate the corresponding environment.