-
Notifications
You must be signed in to change notification settings - Fork 33
2891 Maven Release Plugin
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 perform 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
.
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 Container Registry name space for images. |
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.
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
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
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>
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
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
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 destination 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 artifacts. 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.
- Home
- For BFD Users
- Making Requests to BFD
- API Changelog
- Migrating to V2 FAQ
- Synthetic and Synthea Data
- BFD SAMHSA Filtering