From 3c6782e5ee0cefcad7bae578f00c0d0345339324 Mon Sep 17 00:00:00 2001 From: Saylor Berman Date: Tue, 30 Jul 2024 11:47:53 -0600 Subject: [PATCH] Update release process doc (#2291) Update the release process doc for running tests off of the release branch. --- docs/developer/release-process.md | 31 ++++++++++++++----------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/docs/developer/release-process.md b/docs/developer/release-process.md index b45898295..659492924 100644 --- a/docs/developer/release-process.md +++ b/docs/developer/release-process.md @@ -39,41 +39,38 @@ To create a new release, follow these steps: 1. Create an issue to define and track release-related activities. Choose a title that follows the format `Release X.Y.Z`. 2. Stop merging any new work into the main branch. -3. Test the main branch for release-readiness. For that, use the `edge` containers, which are built from the main - branch, and run the following: - 1. Run the [example applications](/examples) manually and verify their correctness. - 2. Kick off the [NFR workflow](https://github.com/nginxinc/nginx-gateway-fabric/actions/workflows/nfr.yml) in the browser. For `image_tag`, use `edge`, and for `version`, use the upcoming `X.Y.Z` NGF version. This will run all of the NFR tests which are automated and open a PR with the results files when it is complete. Review this PR and make any necessary changes before merging. -4. If a problem is found, prepare a fix PR, merge it into the main branch and return to the previous step. -5. If the supported Gateway API minor version has changed since the last release, test NGINX Gateway Fabric with the previous version of the Gateway API CRDs. -6. If a compatibility issue is found, add a note to the release notes explaining that the previous version is not supported. -7. Create a release branch following the `release-X.Y` naming convention. -8. Run the [Release PR](https://github.com/nginxinc/nginx-gateway-fabric/actions/workflows/release-pr.yml) workflow to update the repo files for the release. Then there are a few manual steps to complete: +3. Create a release branch following the `release-X.Y` naming convention. +4. Once the release branch pipeline completes, run tests using the `release-X.X-rc` images that are pushed to Github (for example, `release-1.3-rc`). + 1. Kick off the [NFR workflow](https://github.com/nginxinc/nginx-gateway-fabric/actions/workflows/nfr.yml) in the browser. For `image_tag`, use `release-X.X-rc`, and for `version`, use the upcoming `X.Y.Z` NGF version. This will run all of the NFR tests which are automated and open a PR with the results files when it is complete. Review this PR and make any necessary changes before merging. + 2. Run the [examples](https://github.com/nginxinc/nginx-gateway-fabric/tree/main/examples) using the release images and verify their correctness. +5. Run the [Release PR](https://github.com/nginxinc/nginx-gateway-fabric/actions/workflows/release-pr.yml) workflow to update the repo files for the release. Then there are a few manual steps to complete: 1. Update the tag of NGF container images used in the [provisioner manifest](/tests/conformance/provisioner/provisioner.yaml). 2. Update the [README](/README.md) to include information about the release. 3. Update the [changelog](/CHANGELOG.md). There is going to be a new blank section generated by the automation that needs to be adjusted accordingly. - At the top there will be a list of all PRs that are labeled with `release-notes`. + - At the top there will be a list of all PRs that are labeled with `release-notes`. The changelog includes only important (from the user perspective) changes to NGF. This is in contrast with the autogenerated full changelog, which is created in the next step. As a starting point, copy the important features, bug fixes, and dependencies from the autogenerated draft of the full changelog. This draft can be found under the [GitHub releases](https://github.com/nginxinc/nginx-gateway-fabric/releases) after the release branch is created. -9. Create and push the release tag in the format `vX.Y.Z`. As a result, the CI/CD pipeline will: + - If the supported Gateway API minor version has changed since the last release, add a note to the release notes explaining if the previous version is no longer supported. +6. Create and push the release tag in the format `vX.Y.Z`. As a result, the CI/CD pipeline will: - Build NGF, NGINX and NGINX Plus container images with the release tag `X.Y.Z` and push them to the registries. - Package and publish the Helm chart to the registry. - Create a GitHub release with an autogenerated changelog and attached release artifacts. -10. Prepare and merge a PR into the main branch to update with similar information that you did in the release branch docs PR. Specifically: +7. Prepare and merge a PR into the main branch to update with similar information that you did in the release branch docs PR. Specifically: 1. [README](/README.md) to include the information about the latest release. 2. [changelog](/CHANGELOG.md). 3. Helm chart `version` field. 4. `GW_API_PREV_VERSION` in tests Makefile, if necessary. 5. Any references in the docs to the previous release. 6. Any installation instructions to ensure that the supported Gateway API and NGF versions are correct. Specifically, helm README. -11. Ask the docs team to update the production branch for NGF in Netlify to our latest release branch and run the deployment pipeline. -12. Close the issue created in Step 1. -13. Ensure that the [associated milestone](https://github.com/nginxinc/nginx-gateway-fabric/milestones) is closed. -14. Verify that published artifacts in the release can be installed properly. -15. Submit the `conformance-profile.yaml` artifact from the release to the [Gateway API repo](https://github.com/kubernetes-sigs/gateway-api/tree/main/conformance/reports). +8. Ask the docs team to update the production branch for NGF in Netlify to our latest release branch and run the deployment pipeline. +9. Close the issue created in Step 1. +10. Ensure that the [associated milestone](https://github.com/nginxinc/nginx-gateway-fabric/milestones) is closed. +11. Verify that published artifacts in the release can be installed properly. +12. Submit the `conformance-profile.yaml` artifact from the release to the [Gateway API repo](https://github.com/kubernetes-sigs/gateway-api/tree/main/conformance/reports). - Create a fork of the repository - Name the file based on the requirements of the [README](https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/reports/README.md). Update the README in the ngf directory and update the site source if necessary (see following example). - Open a PR. [Example](https://github.com/kubernetes-sigs/gateway-api/pull/2514)