Collector build and release-cutting procedure


cd <release-top>/build-scripts
make release

Install and test collector

  • Create / edit a suitable collector configuration file. See gratia/common/configuration/collector-dev.dat or gratia/common/configuration/collector-nbuild.dat for examples.
  • Install with gratia/build-scripts/install-release. Example install from local:
    ${INSTALL_SCRIPT} -t -p -a \
                      $VERSION_OPT $VERSION_ARG \
                      -C ${CONFIG_DIR}/collector-$service.dat \
                      -c $INSTANCE -m $MAILTO
    Invoke install-release --help for an explanation of all the options.
  • Test as appropriate.

Ensure all desired code is committed

svn status
svn commit -m <message> <files> ...

See this SVN primer for more details on SVN use.

Port desired changes to branch

If the current release stream is taking place on a branch, port desired changes from HEAD into the specified branch. For example:

svn checkout
svn merge -r<version-range> .
svn commit -m<message> .

Checking in changes to the whole tree is important because the directory attributes are all updated to reflect which revisions have been merged in from HEAD. This will make future merges simpler and less error-prone.

Then, perform a build and test install of the merged code.

Cut a developer tag

For example:

svn copy{branches/v1-06,development-tags/v1-06-18-rc1}

Export to Gratia releases area and build

cd ~/gratia-releases/
svn export${RELEASE//./-} gratia-${RELEASE}
cd gratia-${RELEASE}/build-scripts
make release

Perform install on nightly build machines

  1. If desired, disable the nightly install command in gratia's crontab on the remote install host:
    #05 0 * * *  /home/gratia/cron-scripts/ --mail
  2. Perform the install on all the nightly build collectors, for example:
    install-nightly-builds -- -R v1.06.18-rc1

Note: if invoked as root, the host credentials for the machine on which install-nightly-builds is executed are obtained before attempting to do the remote installs. Otherwise the user's credentials must be in root's .k5login file on the target install machines.

Copy the final release candidate to the tags arm of the repository

After testing on the nightly install machines and creating as many release candidates as necessary, copy the final release candidate to the release arm:

svn copy{development-tags/v1-06-18-rcX,tags/v1-06-18}

Produce the final build

cd ~/gratia-releases/
svn export${RELEASE//./-} gratia-${RELEASE}
cd gratia-${RELEASE}/build-scripts
make release

Export tarballs for VDT

cd ~/gratia-releases
cp -p gratia-${RELEASE}/target/gratia_*.tar tarballs/
scp -p gratia-${RELEASE}/target/gratia_*.tar

Note: for the copy to FNALU, one should either have membership in the PTS group nichols:wadmgratia or be in the ACL for the /afs/ directory tree. Someone with admin privileges in this area can do:

cd /afs/
find . -type d -exec fs sa -dir \{\} -acl <user> write -print\;

Update the version number on the release page

Update the VDT-team packaging and installation instructions as appropriate, including but not necessarily limited to the TWiki variable ReleaseVersion.

Make sure the release notes are current

Create and/or edit the correct page under the releases section of the main Accounting TWiki page.

Update the ERD if necessary

See John Weigand's notes under the ERD section of the main Accounting TWiki page.

Request a VDT release

Send email to giving URLs from which to obtain the release.

-- ChrisGreen - 27 Jul 2010

Topic revision: r9 - 07 Feb 2017 - 20:23:03 - BrianBockelman
Hello, TWikiGuest


TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..