Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Team:Architecture
Description
official releases build 23 failed:
the reason seems to be that externals packages are tagged from the tip of master instead of that from 18.0.0 existing tag.
Attachments
Activity
I think this ticket can't be closed until an 18.1.0rc1 build succeeds. If I understand the above, the consensus from SQuaRE and DM-CCB is that this should be achieved by Gabriele Comoretto re-running the build with different parameters, rather than by a tooling change from the SQuaRE team. I'm therefore assigning to Gabriele.
After some time investigating, it seems that my understanding, as expressed in the above comment, was not correct.
The extra reference v18.0.0 is required, not by the Jenkins scripts themselves, but by lsstsw implementation logic.
In fact, lsstsw rebuild of lsst_distrib 18.0.0 will fail if not specified the extra reference v18.0.0.
From a release management perspective, 18.0.0 release will build only with v18.0.0 version of DM Externals.
Having this degree of freedom is error-prone and makes the process very weak.
The 18.0.0 release is identified by two tags, and both are needed in order to build properly the release.
This is also confusing from an end-user point of view.
I hope that the external packages will be moved to conda soon, as suggested in DMTN-110, in this way we can speed-up the Science Pipelines release process and make it more robust.
I suggest we consider this issue closed as “Won’t Fix”, as soon as I can restart the 18.1.0 release process.
Requiring 18.0.0 and v18.0.0 is exactly the system we designed. This is driven by the logic in eups that is used to report the git version. Priority is given to tags that start with numbers. Externals are required to use a numbered version tag that matches the version of the external so we use a "v" prefix to work around that constraint.
What I think we could do is tag as we do now (number on our own packages) but also add a "v" tag to every package. Then the "build with v18" logic would be to just use "v18.0.0".
v18.1.0.rc1 is now available. I am closing the issue as "Won't Fix"
No. I prefer not to add an extra unnecessary v18.0.0 where it is not needed. I wait for the conda solution.
This was discussed at DM-CCB today and we also decided that no additional magic should be added.