Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Continuous Integration, dax_ppdb
-
Labels:None
-
Team:Architecture
Description
Failure to build dax_ppdb when doing the official release of 19.0:
Attachments
Issue Links
Activity
Based on the above comment, it seems that DMTN-027 (Renaming an LSST git repository) may require an additional check:
- ensure that no changes in the old package have been introduced after the fork.
and for changes, I am not only referring to code changes, that are quite unlikely to happen but tags.
In this case in fact, during the process, two tags have been added in the old one and have not been propagated to the new one.
I can't be sure, but if this were the case, the official-release job 31 yesterday would not have failed, because of the correct v19.0.0.rc1 tag was found in the new lsst/dax_apdb, and the correct 19.0.0 would have been tagged in the right place.
Said that I am quite reluctant to suggest a change in the tooling. If the renaming of the package is done properly, there should be no problems. In case of a missing tag, the workaround is trivial.
I'm not entirely sure I agree that it would have worked fine if v19.0.0rc1 was present on the dax_apdb repo. How would the tagging script have known to look there when it was applying the 19.0.0 tag? It was looking for dax_ppdb. A 19.0.0 tag appeared (in a weird place) on the dax_ppdb backup repo (and I don't understand how the SHA1 was chosen since it was the SHA1 of HEAD of dax_apdb). I admit I haven't read the tagging code though.
That's thanks to GitHub redirect, which should be working for some time after the renaming.
When the redirect will not work anymore, we will need to add manually the tag, and (re)run the release.
However, old repo and new repo need to be in sync, and now they aren't. That the source of the problem.
After a short chat with Tim Jenness, we agreed that this issue can be closed since the 19.0.0 tag has been applied manually to the correct repository and this made possible to complete the release process.
However, 2 updates are suggested to the renaming procedure (DMTN-027):
- the old package-name should be renamed as legacy_package-name
- an extra check shall be done at the end of the renaming process, in order to ensure that no new changes have been included in the old repository, including tags, especially if the renaming required more than few days.
I open another Jira issue for this.
The two repositories, lsst/dax_apdb, and lsst-dm/dax_ppdb, are supposed to have the same history, from what I have understood since the first is a copy of the second. But they don't.
lsst/dax_apdb is missing w.2019.46 and v19.0.0.rc1 tags, that are instead visible in lsst-dm/dax_ppdb.
This means, something when wrong during the copy, probably it has been done during the weekend when w.2019.46 has been tagged.
It implies also, that the v19.0.0.rc1 has been done before dax_ppdb is moved from lsst to lsst-dm.
We shall add the 2 tags to lsst/dax_apdb in order to make them consistent.