Page History

...

Use the LSST continuous integration system to build the tagged repositories

1. Go to the run-rebuild job
2. Click on `Build with Parameters` linkthe 'Run' button with the blue arrow
3. In the `Branch` first field enter all of the git tags you want to build.  If you enter more than one branch, the build system will resolve them such that the leftmost tag has the highest priority.  Thus, if I were trying to build 2.4.7.sims against the DM weekly w.2017.28, I would enter `2.4.7.sims w.2017.28` into the `Branch` first field.  Any repository that has a 2.4.7.sims tag would use that tag.  Any repository that does not will use w.2017.28.  Any repository that has neither will use master.  This can be extremely helpful if you end up having to amend your release, since you can enter something like `2.4.7.sims.rc2 2.4.7.sims.rc1 w.2017.28` in the event that some repositories need a 2.4.7.sims.rc2 tag to fix bugs discovered when building 2.4.7.sims.rc1.
4. In the `Product` second field, enter the software products that you want to build.  The products that need to be built for a sims release are (in no particular order) `lsst_apps lsst_sims sims_movingObjects sims_operations`.  sims_movingObjects and sims_operations are not official components of lsst_sims.  We build them, though, to make sure that it is possible for users to install versions of these products that are built against the same version of the DM stack as lsst_sims.
5. Check `Skip_Demo` and `Skip_Docs`
6. Click `Build``Run`

This will start a `run_rebuild` job which you should be able to see at the top of the page (the list of green and red dots with numbers next to them).  You will need to refresh your browser to see your build.  When the dot next to your build stops flashing, the build is done.  If the steady dot is green, the build succeeded.  If the steady dot is red, the build failed.  You can click on the number next to the dot and then click `Console Output` to see the stdout report of why the build failed.

Note: This build will probably fail due to Doxygen with a message like

eups list: Unable to find product datarel tagged "b3130"
*** Failed to find datarel "b3130" version.
*** FAILURE: Doxygen document was not installed.

that doesn't actually matter.  Look for a message like

# BUILD b3130 completed.
The DM stack has been installed at /home/jenkins-slave/snowflake/release/lsstsw with tag: b3130.

in the stdout.  That will mean that build succeeded (or, at least, that it succeeded enough for our purposes).

Use the LSST continuous integration system to publish the build

Once your `run-rebuild` job succeeds, go back and tag the repositories with a final X.Y.Z.sims tag (no .rc1, .rc2, etc.) and run `run_rebuild` again (sorry).  After that job completes, navigate to the `Console Output` for that job.  There should be a `BUILD ID` of the form bWXYZ associated with the build (W, X, Y, Z are all integers).  Make a note of that `BUILD ID`

1. Go to the run publish section of the continuous integration system
2. Click `Build with Parameters`the 'Run' button with the blue arrow on it
3. Set `package` (as opposed to `git`); this will control where the build is storedSet `EUPSPKG_SOURCE` to `package`
4. Enter the `BUILD ID` from `run rebuild` into the `BUILD ID` fieldfirst field (this is the bNNNN number)
5. Enter the eups tag you want applied to the release (probably `sims`) into the `TAG` second field
6. Enter the list of products from `run rebuild` into the `Products` third field
7. Click `Build``Run`

This will start a `run publish` job.  When that job is finished, you should be able to `eups distrib install your_product -t your_tag` and get the product and tag that you entered.

...