qserv-dev
tag to get qserv latest
dependencies.
[log in to unmask]" type="cite"> Hello,
It seems we have more and more often to use Qserv dependencies from source (like xrootd or qserv_testdata) during each sprint.
A very simple eups setup would ease a lot this task. This setup is quite robust because it is already used for release procedure (see. https://confluence.lsstcorp.org/display/DM/Qserv+Release+Procedure):
Each time you have updated a Qserv dependency what you could do is:
- Trigger a build in buildbot, verify it is successful (or wait for hourly builds): http://lsst-buildx.ncsa.illinois.edu:8010/waterfall; and get the BUILD ID from the logs (# BUILD ID: bXXX).
- Publish the buildbot build under a temporary eups-tag ("qserv-dev"), e.g., on lsst-dev machine, using lsstsw account:
publish -t qserv-dev -b bXXXX qserv_distrib
were bXX is a buildbot id from the log. To find it, just grep for "BUILD ID" in the buildbot log file.
- Test it (on any machine with web access, the machine should have a qserv repository):
# this script should still work, but I'm not sure as I didn't build any release from a while :-)
# you can also use your own procedure to launch mono-node integration test agains qserv-dev release
bash<qserv repo>
/admin/tools/qserv-install
.sh -i ~
/stack/
-d
And then anyone of us can easily update to the latest eups stack with next command, and we wouldn't have to
think about ad-hoc dependency management.
eups distrib install qserv -t qserv-dev
setup qserv -t qserv-dev
Would you agree to test it?
Cheers,
Fabrice
P.S.: Using this procedure would also ease a lot built and maintenance of a Docker container aimed at development tasks.
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1