...
When the check-in is performed you will notice the revision of the cmt/requirements file, not note this string! You will use it to trigger a build of this HEAD version manually in the next step.
...
The ReleaseManager currently ignores updates along the branches so no HEAD buid will start. However, we can trigger them manually, using one of Navid's ReleaseManager scripts. Assuming you are logged into a noric, you can do:
Wiki Markup
Usage trigger.pl \ [options\]
option:
\--tag The tag to use for the build. For example: rh9_gcc32
\--package The package to build. For example: GlastRelease
\--version The version of the package to build. For example HEAD1.123
\--build The environement to build on. Default value of "" is linux. Other values are windows, ]
option:
--tag The tag to use for the build. For example: rh9_gcc32
--package The package to build. For example: GlastRelease
--version The version of the package to build. For example HEAD1.123
--build The environement to build on. Default value of "" is linux. Other values are windows, mac
Note: for rhel4 builds, the --build option must be set to rhel4
...
It is recommended that systests be performed on the new GR branch HEAD before officially tagging the branch. Ask Leon or Liz!
Tagging Convention
Assuming the system tests went well, we are ready to tag the branch of GlastRelease.
The "p" portion of the tag will be reserved for the case where we are updating GR along a branch. By convention, patch tags start with 1 (one) and are incremented from there as necessary.
...