Skip to content

TaggingAndReleasing

Alan Malta Rodrigues edited this page Aug 20, 2018 · 15 revisions

Definition of the different types of tags in WMCore

Since WMCore is a common repository for several different software/services, we need to have different types of tags where each of them has a different purpose and a different validation. Before discussing them, it's important to mention that we have two types of validation in WMCore, and those define the type of tags we have. The validations are:

  • WMCore validation for CMSWEB: sort of a frontend-wise validation. REST/cherrypy/Couch related code, java script, WMSpecs and some Services modules (like DBS/PhEDEx/StompAMQ). In short, this is how we define when ReqMgr/WMStats/Global WorkQueue/ACDC are ready or not to go to production.
  • WMCore validation for WMAgent: mostly a backend-wise validation, including all the components code, databases interface (couchdb/mysql/oracle), all Services modules, runtime code. The WMAgent validation usually starts from a CMSWEB production-ready release, so a good fraction of the code has already been tested. In short, this is how we define whether a WMCore tag is ready to be used for WMAgent or not.

Regarding the type of tags we create in the WMCore repository, we have:

  • a.b.c.preX : these are pre-release tags which are created several times during the month. As the name suggests, they are not meant to be used by other services, since they're not production ready releases. However, these pre-release tags are requested to be pushed to CMSWEB (testbed and production), so the last pre-release tag in the same cycle can be considered production-ready and so used by other services (e.g. 1.1.14.pre4)
  • a.b.c : this is a final and CMSWEB production-ready release. The latest pre-release tag (the one that went into CMSWEB production) is the baseline for this final release and sometimes they point to the same commit. However, there might be cases with WMAgent side-only changes, that we still add a few PR on top of that before the final release is out.
  • a.b.c.patchX : these tags are only meant for WMAgent, where we create a new branch (usually branching off the final release) such that we can isolate changes needed by WMAgents. This way, all WMAgent bug fixing has to be done against this special branch (named as a.b.c_wmagent), and a new patch tag is released. In addition to that, we usually have the same fix pushed to the master branch as well.
  • a.b.c.cmswebX : only used for critical fix in CMSWEB production. So another branch is created from the latest pre-release (the one in CMSWEB production) and the required fix is pushed to that branch (and master, of course), then a new tag is release and asked to be put in CMSWEB production.

Cutting and releasing a new tag in github

It's suggested to start this procedure in a fresh new terminal/repository to avoid any surprises. First, we clone the WMCore repository:

amaltaro@vocms055:/build/amaltaro $ git clone git@github.com:dmwm/WMCore.git && cd WMCore

Then we use the bin/buildrelease.sh script to cut a tag, it will basically:

  • update the CHANGES file with the last changes for that specific branch
  • commit this file and create a new tag
  • push these changes to the remote repository.

You can see the helper function with:

amaltaro@vocms055:/build/amaltaro/WMCore $ sh bin/buildrelease.sh -h
Tag & build a WMCore/WMAgent release
buildrelease.sh [options]

options:
  -r        Remote repository to update, default to origin.
  -g     Git branch to be tagged, default to master.
  -t           Tag name to be created.
  -h                Show this helper.

If you are cutting a tag against the master branch, your command line would be something like (don't forget updating your tag):

amaltaro@vocms055:/build/amaltaro/WMCore $ ./bin/buildrelease.sh -t 1.0.14.patch2

the command above would create the 1.0.14.patch2 tag against the master branch, which is the default in case you do not provide any branch. During the process, it will open vi editor such that you can edit the CHANGES file. The CHANGES file usually contain two commits per change (a merge and the actual commit). After you are done with these changes, save and close the editor. It will then tag and push this commit + tag to the remote repository.

In case you're tagging a specific branch, your command line would look like (don't forget updating the branch and tag in the command line below):

amaltaro@vocms055:/build/amaltaro/WMCore $ ./bin/buildrelease.sh -g 1.0.14_wmagent -t 1.0.14.patch2

which would tag the 1.0.14_wmagent branch with a tag 1.0.14.patch2, CHANGES file would be updated reflecting all changes made in this branch.

Clone this wiki locally