Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • groovyVersion : normal Groovy version
    • release value is the version you want to publish. In the screenshot, we want to release Groovy 2.3.0-rc-2
    • next integration value is the value of the version is we want on VCS after the release. Since here it's a RC, we want to switch back to 2.3.0-SNAPSHOT. In a final release, this usually corresponds to X.Y.(Z+1)-SNAPSHOT
  • groovyBundleVersion : OSGI specific version
    • release value is the version you want to publish. In the screenshot, we want to release Groovy 2.3.0.rc-2
    • next integration value is the value of the version is we want on VCS after the release. Since here it's a RC, we want to switch back to 2.3.0.SNAPSHOT. In a final release, this usually corresponds to X.Y.(Z+1).SNAPSHOT
  • checkout branch is very important and corresponds to the branch we want to release from. In the screenshot, we are releasing from the GROOVY_2_3_0_RC_X branch
  • Use release branch is not mandatory. If checked, then a specific branch will be used to release. This can be useful if you expect commits to be pushed while a release is in progress.
  • Create VCS tag should always be checked. Put here the name of the release tag to be pushed after the release is done.
  • Artifactory configuration: choose the oss-release-local repository.
  • Staging comment is useful when we go to the artifactory UI. Put here a comment about the release.

  • Then click on "Build and Release to Artifactory"

 

The release will be queued and executed once build agents are available.

Info
titleMissing release branch

If you don't see the branch you want to release from in the "checkout branch" list, then you need to first start a dummy build on that branch using the regular "run" button instead of the artifactory release management tab. This will inform the artifactory plugin that a new branch can be used as a release branch. Before doing so, it is recommanded that you temporarily disable the "groovy" and "documentation" build steps, then restore them once the branch is visible in the release management tab.

Recovering a failure with Artifactory/Bintray

The release process includes a critical build step that does all the required job to synchronize with artifactory, Bintray and Maven Central. Unfortunately, the process is not rock solid so errors may appear during the build. This explains how you can recover. First of all, you need to know:

  • the build number which failed
  • the directory where artifacts are published. This you can find in the build log (check a line like [14:08:08]: Checkout directory: /var/teamcity/buildagent-jdk7/work/c88d543299f59f28)

You need root access to the CI server. Login to the CI server. You should find a directory named /tmp/release. Inside, you'll find a copy of the groovy build step. If the directory and the script isn't here, no problem, you can copy it.

Edit the script and replace the following lines:

  • def buildDir = new File(system.get('teamcity.build.checkoutDir')) -> def buildDir='/path/to/build/dir'
  • def version= configParams['org.jfrog.artifactory.releaseManagement.releaseVersion_groovyVersion'] -> def version = 'groovy-xxx'
  • def buildNumber = configParams['build.number'] -> def buildNumber = '35'

The script uses log.message and log.error, which are not defined if you copied the script from the build step. If this is the case, add the following line after "def buildNumber=":

  • def log = [message: { println it }, error: {println it} ]

then you will find a number of flags that tell which step should be executed. Update the flags accordingly to the steps which failed, then execute the script.

 

Instructions (for 2.0+ releases)

...