Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Continuous Integration, stack release
-
Labels:None
-
Story Points:4.25
-
Epic Link:
-
Team:SQuaRE
Description
The nightly release pipeline failed trying to publish eupspkg after the touchstone build. This is not a failure mode I have personally observed before.
+ publish -b b3546 -t d_2018_04_13 lsst_distrib qserv_distrib
|
eupspkg.create: package contents created for 'lsst_distrib-15.0-2-gda316d8+4', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'doxygen-1.8.13.lsst1-1-g75bf114', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'python-0.0.7-1-g28a652d', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'astropy-2.0.1+1', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'boost-1.66.0+1', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'numpy-1.13.1+1', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'pep8_naming-0.4.1+2', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'pycodestyle-2.3.1+2', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'pyflakes-1.6.0+1', sources will be fetched via 'git'. |
eupspkg.create: package contents created for 'pykg_config-1.3.0+3', sources will be fetched via 'git'. |
eupspkg.create (fatal): failed to resolve repository for pytest-3.2.0.lsst2+1 using REPOSITORY_PATH='/home/jenkins-slave/snowflake/release/lsstsw/build/$PRODUCT'. Check the path or accessibility of your git repositories. |
eups distrib: Command:
|
source "/home/jenkins-slave/snowflake/release/lsstsw/eups/2.1.4/bin/setups.sh"; export EUPS_PATH="/home/jenkins-slave/snowflake/release/lsstsw/stack"; cd /tmp/tmpzs6trr_2.eupspkg/pytest-3.2.0.lsst2+1 && /home/jenkins-slave/snowflake/release/lsstsw/eups/2.1.4/lib/eupspkg.sh PREFIX=/home/jenkins-slave/snowflake/release/lsstsw/stack/Linux64/pytest/3.2.0.lsst2+1 PRODUCT=pytest VERSION=3.2.0.lsst2+1 FLAVOR=generic VERBOSE=0 create |
Attachments
Issue Links
Activity
The kludge of putting a w.2018.15 git tag back and rerunning with forced tag updates worked; w_2018_15 shipped yesterday evening. However, I'm still working on improving github_tag_version to handle the previous tag present in only some repos scenario.
github_tag_version from sqre-codekit has been heavily refactored to improve maintainability and debug messages along with handled when a tag needs to be created vs updated. The script can now also be rerun for verification without reporting errors on the existing tags (it checks that they are pointing to the correct sha).
I've tagged as 4.0.0 and released to pypi / docker hub. Jenkins will attempt to use 4.0.0 when tagging the nightly release, so I'm going to put this ticket into self review to follow up tomorrow.
The nightly-release "tagging", which is only a "dry run" and does not create tags, looks OK: https://ci.lsst.codes/blue/organizations/jenkins/release%2Fnightly-release/detail/nightly-release/267/pipeline/93
On second thought, I'm going to leave this ticket open until after the next weekly to ensure that tag creation is working.
Tagging succeeded as part of the re-run of w_2018_16 last night.
I've spot checked a few repos and the w.2018.16 git tag is present.
The problem is that when the tagging script from sqre-codekit is in forced tag update mode, it fails over when the tag does not already exist in the repository – this is the github api semantics. A tag has to either be deleted and recreated or update'd and the later fails if the tag does not already exist. I'm working on sqre-codekit but I'm going to put a w.2018.15 tag back on the current master of the updated repos and try to rerun the weekly.