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
