Please note that this procedure would also allow CI to easilly build
latest version of our dependencies. And this is required to launch
integration test in CI.
Indeed for now, Jenkins doesn't use latest version of our depencies in a
build, check for example qserv_testdata version (2015_08) in latest
build log:
https://ci.lsst.codes/job/qserv-os-matrix/label=centos-7/1747/console
Procedure below would allow Jenkins to use|*qserv-dev*| tag to get qserv
latest dependencies.||
Maybe we could talk about this next week?
Cheers,
On 10/30/2015 09:57 AM, Fabrice Jammes wrote:
> 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
