Project

General

Profile

Making JobSub Releases

NOTE: NEVER COMMIT COMPILED BINARIES/TARBALLS/RPMS/PYC/PYO files to the GIT. GIT repo should only contain documentation and source code.

Releasing New Version

Releasing JobSub Server rpm

These instructions assumes: release version v0.1 and release branch branch_v0.1 for the v0.1.x series and you are releasing jobsub-0.1-1.noarch.rpm

  • Checkout the release branch
       git checkout branch_v0.1
       git pull
  • Make required changes and test them. Update the spec file
    • Set the version field. "Version: 0.1"
    • Reset the release field. "Release: 1"
    • Add an entry to the "%changelog" section
  • Create a test rpm
  • Test your changes
  • Commit changes if any
      git commit .
  • Create an annotated git tag
      git tag -a v0.1
  • Push the changes and tags to remote repository
      git push
      git push --tags

Releasing JobSub Client Tarball

Eventually, these steps should be converted to a release script.

  • Assuming you have already created a git tag as part of the server release, checkout the write tag
      git checkout v0.1
  • Create a jobsub-client-v0.1.tar.gz containing only following files/directories
    • jobsub/LICENSE.txt
    • jobsub/doc
    • jobsub/client

Releasing jobsub_tools to UPS/UPD

  • Checkout the release branch
       git checkout <branch name>
       git pull
  • Make required changes and test them. Update the ups table file * Update $VERS and $REV in the script that generates the table file, jobsub/jobsub_tools/dist_jobsub.sh
          [dbox@fermicloud326 git-3-20-14]$ head jobsub/jobsub_tools/dist_jobsub.sh 
          #!/bin/sh 
          VERS=v1_2
          REV=x
          ./make_tablefile.py $VERS$REV
    
          if [ "$1" ==  "" ]; then
          echo "usage $0 target_machine" 
          echo "tars up jobsub_tools and distributes it to /fnal/ups/prd" 
          exit -1
          fi
          
    • Update release notes in jobsub/jobsub_tools/prd/jobsub_tools/${VERS}/Linux-2/README
  • Test your changes
    • Generate ups/upd test instance on test machine using dist_jobsub.sh
      • fermicloud nodes are convenient test machines, as you have root and can install rpms and do other mods as needed. To install at a minimum the test machine needs:
        • ups/upd installed in /fnal/ups
        • you (the distributor) in the products account .k5login file
      • ./dist_jobsub.sh test_machine
      • ssh test_machine
      • source /fnal/ups/etc/setups.sh
      • setup jobsub_tools
      • test your changes
        • jobsub yada yada yada
  • Commit changes if any
      git commit .
  • Create an annotated git tag
      git tag -a jobsub_tools-<version>
  • Push the changes and tags to remote repository
      git push
      git push --tags
  • Release the product to UPS/UPD
    • push the tagged ups/upd product again to your test machine with dist_jobsub.sh
    • test it again just to be sure its what you intended to release
    • distribute to ftp.fnal.gov KITS area
      • source /fnal/ups/etc/setups.sh
      • setup ups
      • setup upd
      • upd addproduct jobsub_tools (version)
        • (version) matches $VER$REV in dist_jobsub.sh
      • send mail to announcing new release
      • open service desk ticket to have release installed where users can find it

Releasing jobsub_client to UPS/UPD

  • jobsub_client ups product is built from jobsub_client tarball using script jobsub/ups_jobsub_client/dist_jobsub_client.sh
  • to use this script you must be in the .k5login for user 'products' on the target machine
  • usage: dist_jobsub_client.sh target-machine release-version url-to-tarball
         $ cd jobsub/ups_jobsub_client
         $ ./dist_jobsub_client.sh novagpvm01 v1_0 https://cdcvs.fnal.gov/redmine/attachments/download/20188/jobsub-client-v1.0.tgz
         
  • after running dist_jobsub_client.sh ssh to target-machine and test
  • after testing, put in ftp.fnal.gov KITS area like is done for jobsub_tools
    • source /fnal/ups/etc/setups.sh
    • setup ups
    • setup upd
    • upd addproduct jobsub_client (version) -f NULL
      • (version) matches release-version in dist_jobsub_client.sh
  • send mail to < email list > announcing new release
  • open service desk ticket to have release installed where users can find it
    • for release candidates this usually means release to /grid/fermiapp/products/common and have the product declared 'test'
    • ssh products@(some machine that mounts /grid/fermiapp/products/common)
    • source /grid/fermiapp/products/common/etc/setups.sh
    • setup ups
    • setup upd
    • upd install jobsub_client (version) -f NULL
    • ups declare -t jobsub_client (version) -f NULL
    • ask Lynn Garren to install this version of jobsub_client on the cdf cluster

Releasing new rpm but same JobSub version

At times, the RPM released might require changes without actually packing new code. This can happen under following circumstances

  • Add missing files to rpm
  • Change the permissions of the files
  • Address packaging issues

Steps For Releasing a New RPM

These instructions assumes: release version v0.1 and release branch branch_v0.1 for the v0.1.x series and you are releasing jobsub-0.1-2.noarch.rpm to replace jobsub-0.1-1.noarch.rpm

  • Checkout the release branch
       git checkout branch_v0.1
       git pull
  • Update the spec file to make required changes
    • Increment the number pointed by "Release: 2"
    • Add an entry to the "%changelog" section
  • Create a test rpm
  • Test your changes
  • Commit the spec file
      git commit packaging/jobsub_server.spec
  • Create an annotated git tag
      git tag -a v0.1-2
  • Push the changes and tags to remote repository
      git push
      git push --tags

Making the Release files available

  • Upload the client tar file and the server rpms to the Files page in the wiki. Assign them correct release version.