Skip to content

Latest commit

 

History

History
151 lines (110 loc) · 6.04 KB

releasing.md

File metadata and controls

151 lines (110 loc) · 6.04 KB

ip-address-manager releasing

This document details the steps to create a release for ip-address-manager aka IPAM.

NOTE: Always follow release documentation from the main branch. Release documentation in release branches may be outdated.

Before making a release

Things you should check before making a release:

  • Check the Metal3 release process for high-level process and possible follow-up actions
  • Use the ./hack/verify-release.sh script as helper to identify possible issues to be addressed before creating any release tags. It verifies issues like:
    • Verify CAPI go module is the latest in root Go module.
    • Verify controller Go modules use latest corresponding CAPI modules
    • Verify any other direct or indirect dependency is uplifted to close any public vulnerabilities

Process

IPAM uses semantic versioning.

  • Regular releases: v1.x.y
  • Beta releases: v1.x.y-beta.z
  • Release candidate releases: v1.x.y-rc.z

Repository setup

  • Clone the repository from your intended fork: git clone [email protected]:[your-fork]/metal3-ipam.git

or if using existing repository, make sure origin is set to the fork and upstream is set to metal3-io. Verify if your remote is set properly or not by using following command git remote -v.

  • Fetch the remote (metal3-io): git fetch upstream This makes sure that all the tags are accessible.

Creating Release Notes

  • Switch to the main branch: git checkout main

  • Create a new branch for the release notes**: git checkout -b release-notes-1.x.x origin/main

  • Generate the release notes: RELEASE_TAG=v1.x.x make release-notes

    • Replace v1.x.x with the new release tag you're creating.
    • This command generates the release notes here releasenotes/<RELEASE_TAG>.md .

  • Next step is to clean up the release note manually.

    • If release is not a beta or release candidate, check for duplicates, reverts, and incorrect classifications of PRs, and whatever release creation tagged to be manually checked.
    • For any superseded PRs (like same dependency uplifted multiple times, or commit reversions) that provide no value to the release, move them to Superseded section. This way the changes are acknowledged to be part of the release, but not overwhelming the important changes contained by the release.

  • Commit your changes, push the new branch and create a pull request: IMPORTANT_NOTE:

    • The commit and PR title should be 🚀 Release v1.x.y: -git commit -S -s -m ":rocket: Release v1.x.x" -git push -u origin release-notes-1.x.x
    • Important! The commit should only contain the release notes file, nothing else, otherwise automation will not work.

  • Ask maintainers and release team members to review your pull request.

Once PR is merged following Github actions are triggered:

  • Github action Create Release runs following jobs:
    • Github job push_release_tags will create and push the tags. This action will also create release branch if its missing and release is rc or minor.
    • Github job create draft release creates draft release. Don't publish the release until release tag is visible in. Runningactions are visible on the Actions page, and draft release will be visible on top of the Releases. If the release you're making is not a new major release, new minor release, or a new patch release from the latest release branch, uncheck the box for latest release. If it is a release candidate (RC) or a beta release, tick pre-release box.
  • Github action build-images-action is triggered once tags are pushed from above action. This action builds release image with the release tag in Jenkins, and it gets pushed to Quay. Make sure the release tag is visible in Quay tags page. If the release tag build is not visible, check if the action has failed and retrigger as necessary.

Release artifacts

We need to verify all release artifacts are correctly built or generated by the release workflow.

We can use ./hack/verify-release.sh to check for existence of release artifacts, which should include the following:

Git tags pushed:

  • Primary release tag: v1.x.y
  • Go module tag: api/v1.x.y

Container images at Quay registry:

Files included in the release page:

  • A manifest file - ipam-components.yaml

Make the release

After everything is checked out, hit the Publish button your GitHub draft release!

Post-release actions for new release branches

Patch release process is complete, but further additional actions are required in the Metal3 project to take in the new major or minor release. These steps are documented in Metal3 release process

Branch protection rules

Branch protection rules need to be applied to the new release branch. Copy the settings after the previous release branch, with the exception of Required tests selection. Required tests can only be selected after new keywords are implemented in Jenkins JJB, and project-infra, and have been run at least once in the PR targeting the branch in question.

Build badges

Update the build badges in the README.md to point to correct Jenkins jobs, so the status of the release branch is visible.

Example

Additional actions outside this repository

Further additional actions are required in the Metal3 project after IPAM release. For that, please continue following the instructions provided in Metal3 release process