Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: jenkins
-
Labels:None
-
Team:Architecture
-
Urgent?:No
Description
The release process is creating a manifest that uses eups package versions that include 22.0.1 (e.g. versiondb b5788). But when it later goes to do builds, those stacks seem to setup some packages with versions that use 22.0.0 (and do not include the build tag such as b5789). This carries over to the publish step and the exact versions in expanded table files, causing simple setup commands to fail in the resulting containers.
Attachments
Issue Links
- blocks
-
DM-29437 Do Release 23.0.0 of Science Pipelines
- Done
Activity
Looks okay since it seems to work. Do you need me to hit the merge button on github?
Yes, please, and a release, too.
New release pushed.
Basically, --points-at returns nothing.
$ git tag -l "[0-9.]*" --points-at v23.0.0.rc1$ git tag -l "[0-9.]*" --contains v23.0.0.rc122.0.022.0.1$ git tag -l "[0-9]*" --points-at $(git rev-parse "v23.0.0.rc1^{commit}")22.0.022.0.1It looks like bare --points-at would return the tag specified (and only that tag) if it matched the pattern, but that's not what is desired anyway. I believe this has to do with the difference between <object> and <ref> or <commit> as a git argument.
On the other hand, I'm now convinced that --contains is incorrect as well, as it will list later tags that contain the given ref, but those are inappropriate for versioning use. So I think we're down to the last alternative.