WDT project release process
This document describes the process that should be followed to create a WebLogic Deploy Tooling (WDT) release.
Prerequisites
- A local installation of WebLogic Server 12.2.1.x must be available.
- The person running the release process must have admin privileges on the WebLogic Deploy Tooling GitHub repo because the release process pushes to the master branch directly.
- The person running the release process needs to create a GitHub Personal Access Token for the repository with (at least) the
repo:status,repo_deployment,public_repo, andsecurity_eventsprivileges. - The person running the release process needs a server added to their Maven
settings.xmlfile, where the GitHub Personal Access Token is stored, as shown below. Note that this token can either be stored in plain text or encrypted using Maven password encryption .
- If the machine from which the release process is being run requires a proxy server to access the Internet, the person running the release process needs an active proxy configured in their Maven
settings.xmlfile.
Software release process
The best practice is to write the release notes that will be published to GitHub prior to starting the steps below.
-
Set (and export) the following environment variables:
WLST_DIR- set to$MW_HOME/oracle_common/common/bin, where$MW_HOMEis the path to a WLS 12.2.1.x or newer installation directory.WDT_SCM_REPO_URL- set to the browsable URL to the project (e.g.,https://github.com/oracle/weblogic-deploy-tooling)WDT_SCM_REPO_CONN- set to the clonable URL for the project (e.g.,git@github.com:oracle/weblogic-deploy-tooling.git)
-
When releasing as part of the Oracle infrastructure, you must make sure to wait until all Jenkins build activity associated with the
mainbranch is complete prior to starting the release process. -
In the
weblogic-deploy-toolingproject directory, run themvn -B release:prepare release:performcommand.- If the next development version is changing the major or minor version, override the default
developmentVersionproperty on the command line. For example,
mvn -B -DdevelopmentVersion=3.2.0-SNAPSHOT release:prepare release:perform. - If your SSH private key has a passphrase, watch the build closely because it will prompt for your passphrase multiple times. Failure to enter it in a timely manner may result in a failure.
- If the next development version is changing the major or minor version, override the default
-
If the build fails, run the
mvn -B release:rollbackcommand to undo it and start over from Step 2., after correcting the issue. -
After the software has been released, move on to the GitHub Release Process.
GitHub release process
Note that this process relies on the WDT installers being in your local Maven repository. As such, it is critical for the same user to run these steps on the same machine as the steps from the previous section!
- Prior to starting the GitHub release, you must wait until all Jenkins activity triggered by the release is complete.
- Save the release notes in the file
<wdt-project-directory>/target/ReleaseNotes.md. - Run the command
mvn -f github-release.xml -DreleaseVersion=<release version number> verifyto create the draft GitHub Release. - Log into GitHub , go to the Releases page, review/edit the draft release, and then publish the release.