Documentation
Introduction
- Overview
- Getting Started
- Support for K8s Installers
- Deploying on Kind
- Deploying on Minikube
- Configuration
- Installing with Helm
Cloud Deployment
Reference
- Antrea Network Policy
- Antctl
- Architecture
- Traffic Encryption (Ipsec / WireGuard)
- Securing Control Plane
- Security considerations
- Troubleshooting
- OS-specific Known Issues
- OVS Pipeline
- Feature Gates
- Antrea Proxy
- Network Flow Visibility
- Traceflow Guide
- NoEncap and Hybrid Traffic Modes
- Egress Guide
- NodePortLocal Guide
- Antrea IPAM Guide
- Exposing Services of type LoadBalancer
- Traffic Control
- Versioning
- Antrea API Groups
- Antrea API Reference
Windows
Integrations
Cookbooks
Multicluster
Developer Guide
Project Information
Antrea Release Process
This file documents the list of steps to perform to create a new Antrea
release. We use <TAG> as a placeholder for the release tag (e.g. v1.4.0).
-
For a minor release On the code freeze date (typically one week before the actual scheduled release date), create a release branch for the new minor release (e.g
release-1.4).- after that time, only bug fixes should be merged into the release branch, by cherry-picking the fix after it has been merged into main. The maintainer in charge of that specific minor release can either do the cherry-picking directly or ask the person who contributed the fix to do it.
-
Open a PR (labelled with
kind/release) against the appropriate release branch with the following commits:- a commit to update the
CHANGELOG. For a minor release,
all significant changes and all bug fixes (labelled with
action/release-notesince the first version of the previous minor release should be mentioned, even bug fixes which have already been included in some patch release. For a patch release, you will mention all the bug fixes since the previous release with the same minor version. The commit message must be exactly"Update CHANGELOG for <TAG> release", as a bot will look for this commit and cherry-pick it to update the main branch (starting with Antrea v1.0). The prepare-changelog.sh script may be used to easily generate links to PRs and the Github profiles of PR authors. Useprepare-changelog.sh -hto get the usage. - a commit to update
VERSION as needed, using the following
commit message:
"Set VERSION to <TAG>". Before committing, ensure that you runmake -C build/charts/ helm-docsand include the changes.
- a commit to update the
CHANGELOG. For a minor release,
all significant changes and all bug fixes (labelled with
-
Run all the tests for the PR, investigating test failures and re-triggering the tests as needed.
- Github worfklows are run automatically whenever the head branch is updated.
- Jenkins tests need to be triggered manually.
- Cloud tests need to be triggered manually through the
Jenkins web UI. Admin access is
required. For each job (AKS, EKS, GKE), click on
Build with Parameters, and enter the name of your fork asANTREA_REPOand the name of your branch asANTREA_GIT_REVISION. Test starting times need to be staggered: if multiple jobs run at the same time, the Jenkins worker may run out-of-memory.
-
Request a review from the other maintainers, and anyone else who may need to review the release notes. In case of feedback, you may want to consider waiting for all the tests to succeed before updating your PR. Once all the tests have run successfully once, address review comments, get approval for your PR, and merge.
- this is the only case for which the “Rebase and merge” option should be used instead of the “Squash and merge” option. This is important, in order to ensure that changes to the CHANGELOG are preserved as an individual commit. You will need to enable the “Allow rebase merging” setting in the repository settings temporarily, and remember to disable it again right after you merge.
-
Make the release on Github with the release branch as the target and copy the relevant section of the CHANGELOG as the release description (make sure all the markdown links work). You typically should not be checking the
Set as a pre-releasebox. This would only be necessary for a release candidate (e.g.,<TAG>is1.4.0-rc.1), which we do not have at the moment. There is no need to upload any assets as this will be done automatically by a Github workflow, after you create the release.- the
Set as the latest releasebox is checked by default. If you are creating a patch release for an older minor version of Antrea, you should uncheck the box.
- the
-
After a while (time for the relevant Github workflows to complete), check that:
- the Docker image has been pushed to dockerhub with the correct tag. This is handled by a Github worfklow defined in a separate Github repository and it can take some time for this workflow to complete. See this document for more information.
- the assets have been uploaded to the release (
antctlbinaries and yaml manifests). This is handled by theUpload assets to releaseworkflow. In particular, the following link should work:https://github.com/antrea-io/antrea/releases/download/<TAG>/antrea.yml.
-
After the appropriate Github workflow completes, a bot will automatically submit a PR to update the CHANGELOG in the main branch. You should verify the contents of the PR and merge it (no need to run the tests, use admin privileges).
-
For a minor release Finally, open a PR against the main branch with a single commit, to update VERSION to the next minor version (with
-devsuffix). For example, if the release was forv1.4.0, the VERSION file should be updated tov1.5.0-dev. Before committing, ensure that you runmake -C build/charts/ helm-docsand include the changes. Note that after a patch release, the VERSION file in the main branch is never updated, so no additional commit is needed.