Print

---

[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

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