Skip to content

2891 Maven Release Plugin

Brian Burton edited this page Sep 20, 2023 · 6 revisions

Release Plugin Instructions

Overview

The Maven release plugin coordinates the process of building a tagged release, readying poms for the next development iteration, and publishing the build artifacts. The plugin also takes care of keeping the version numbers in all poms up to date with the next release version. See the documentation for detailed instructions on using the plugin. This document explains the basic steps necessary to performn a release manually. Batch mode is also available to facilitate automating builds but this document does not cover that.

Some maven settings are specific to performing a release and are not desirable during normal development. These settings are defined in the root pom as a maven build profile named test-release.

Environment Variables

You must set up the following environment variables before performing a release.

Variable Name Description
CA_OWNER Numeric string defining the AWS account owner.
CA_DOMAIN Name of the CodeArtifact domain containing your repository.
CA_REPOSITORY Name of the CodeArtifact repository.
CA_REPOSITORY_ENDPOINT CodeArtifact repository URL (as provided by AWS Console instructions).
ECR_REPOSITORY_NAMESPACE Elastic Conatiner Registry name space for images.

AWS Credentials

You must set up some temporary AWS credentials before performing a release. Here we assume you are using aws-vault or have a token already established before executing these commands. This method is compatible with both Docker Desktop and Colima.

Install ECR credentials for use by docker

The token returned by get-login-password expires after 12 hours. There are other ways to set up authentication but this is the simplest.

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $ECR_REPOSITORY_NAMESPACE

Install CodeArtifact credentials for use by maven

The token returned by get-authorization-token expires after 12 hours.

export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token --domain $CA_DOMAIN --domain-owner $CA_OWNER  --region us-east-1 --query authorizationToken --output text`sh

Maven Settings

Your $HOME/.m2/settings.xml file will need to have a server element for the CodeArtifact repository. You must have a server element in your settings.xml file with an ID matching your CA_REPOSITORY value so that maven knows how to authenticate with CodeArtifact. For example if CA_REPOSITORY is set to bfd-mgmt-bfd-release-hackathon your settings.xml file should look something like this:

<?xml version="1.0" encoding="utf-8"?>
<settings>
    <servers>
        <server>
            <id>bfd-mgmt-bfd-release-hackathon</id>
            <username>aws</username>
            <password>${env.CODEARTIFACT_AUTH_TOKEN}</password>
        </server>
    </servers>
</settings>

Prepare the release

The prepare goal tells the maven release plugin to assign a new version number throughout the project, build the new version, check in that change, and then create a new commit with the next SNAPSHOT release assigned to all poms. It is this step that does the "release" at the source control level and ECR level.

Side effects of this step are:

  • Tag created in repository.
  • Release commit pushed to origin.
  • Images updated in ECR.

NOTES:

  • The profile test-release sets up property overrides necessary for pushing the images to ECR as well as some other things.
  • We currently rely on SNAPSHOT releases of the two bfd-data- modules. Until we fix that we need the -DignoreSnapshots=true.
mvn release:prepare -P test-release -DignoreSnapshots=true

Finalize the release

The perform goal should be run immediately after prepare to push all of the release artifacts to CodeArtifact.

Side effects of this step are:

  • All maven build artifacts pushed to CodeArtifact.
mvn release:perform -P test-release

Testing the process

Running the maven release plugin produces permanent side effects in the following places:

  • CodeArtifact: Pushes build artifacts to a repository.
  • Elastic Container Registry: Pushes docker images to a registry.
  • Github: Adds commits to the current branch for the release and new development, adds tags, and pushes it all to remote repository.

To perform local development/testing of the maven release plugin settings you need to neutralize all of these side effects. This section explains how that can be done.

Clone the BFD git repository from github into a local branch. (use --bare during the clone!) You will use this as an alternative destrination for release commits and tags.

Check out a feature branch for your development/test. You will do all of your changes and testing using this branch. Add the bare repository as a new remote in your working git repo:

Edit your apps/pom.xml file to change the connection and developerConnection in the scm element to point to your local repo instead of github. The connection URL will have the format git:file://localhost/absolute-path-to-local-bare repository-directory.

Create a new CodeArtifact repository to receive your testing build articacts. You can do this in the AWS console.

Create a new ECR repository to hold docker images.

Update settings.xml and environment variables to match.

Now you can do releases in the test environment without impacting the real github and AWS repositories.

Clone this wiki locally