Versions Compared

Key

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

Instructions (for 2.2+ releases)

Releases are now directly made from the CI server, which dramatically simplifies the procedure. Basically, the process is fully automated and only involves filling a form. The CI server will take care of:

  • checking out the sources
  • running the test suite against the release version of the JDK
  • build the artifacts
  • upload the artifacts to Bintray
  • synchronize the version with Maven Central
  • unzip the documentation to the web server
  • tag and push the tag

First step is to login to the CI server. You need a priviledged account to perform a release. If you don't have such an account, ask the Groovy project manager.

This is where you will be able to perform the release. You need to fill the form with the following values:

Image Added

  • 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)

Info
titleJDK 7 mandatory

Make sure you are using a Java 7 JDK, otherwise Groovy would be compiled without invoke dynamic support

...

Code Block
./gradlew clean dist

 

  • Upload all the zips from ./target/distributions/ (but not jars) to the WebDAV distribution site (httpssitehttps://dav.codehaus.org/dist/groovy/distributions), for example, or through rsync if you're authorized:

    Code Blockrsync -vlogDrzP

  • Upload the javadocs from ./target/

    distributions/*.zip $USER@groovy.codehaus.org:/projects/groovy/dist/

    (just check they are in the right place afterwards; you may still need a webdav client to move them into the right subdirectories if something goes wrong)

    Upload the javadocs through rsync to the html/ to the WebDAV web site (https://dav.codehaus.org/groovy/), for example:

    Code Block
    rsync -vlogDrzP ./target/html/* $USER@groovy.codehaus.org:/projects/groovy/web/
  • Put m2 jars into right place for uptake into repo1 (see Publishing artifacts on Building Groovy from Sourcefor more details):

    Prior to uploading, you must make sure you have rights to upload artifacts to the CodeHaus repository. If so, you must have two system properties set before uploading:

    Code Block
    groovy.deploy.username
    groovy.deploy.password

    Then you may upload artifacts using the following command (note there are lots of artifacts to upload, do not be surprised if it takes more than an hour):

    Code Block
    ./gradlew clean uploadArchives
    

    Or with the user / password passed as properties:

    Code Block
    ./gradlew -Dgroovy.deploy.username=USER -Dgroovy.deploy.password=PASSWORD clean uploadArchives

    Should there be a problem when uploading the jars, check that there is a file ~/.m2/settings.xml containing:

    Code Block
    XML
    XML
    <?xml version="1.0"?>
    <settings>
      <servers>
        <server>
          <id>codehaus.org</id>
          <username>USER</username>
          <password>PASSWORD</password>
        </server>
      </servers>
    </settings>
    

    Where USER and PASSWORD are replaced if the right values.

  • If you are affected by authentication issues, due to the odd certificates used by Codehaus, and if the installation of those certificates are problematic on your machine (if the certificates are rejected or if you're not running as root, etc), you can use a local keystore:

    Code Block
    languagebash
    sudo $JAVA_HOME/bin/keytool -import -alias StartSSL-CA -file ~/Downloads/startssl-CA.pem -keystore ~/.keystore 
    sudo $JAVA_HOME/bin/keytool -import -alias StartSSL-Intermediate -file ~/Downloads/startssl-Intermediate.pem -keystore ~/.keystore 
     
    export JAVA_OPTS="-Xmx2048M -Djavax.net.ssl.keyStore=$HOME/.keystore -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.ssl.trustStore=$HOME/.keystore -Djavax.net.ssl.trustStorePassword=changeit"
    
    ./gradlew -Dgroovy.deploy.username=USER -Dgroovy.deploy.password=PASSWORD uploadArchives

...