You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the new deployment model, the provisioner mode for conformance tests is no longer needed. This code is removed, and at a later date the conformance tests will be updated to work with the new model. Renamed the "static-mode" to "controller".
Also removed some unneeded metrics collection.
Copy file name to clipboardExpand all lines: docs/developer/release-process.md
+2-3
Original file line number
Diff line number
Diff line change
@@ -44,9 +44,8 @@ To create a new release, follow these steps:
44
44
1. Kick off the [longevity tests](https://github.com/nginx/nginx-gateway-fabric/blob/main/tests/README.md#longevity-testing) for both OSS and Plus. You'll need to create two clusters and VMs for this. Before running, update your `vars.env` file with the proper image tag and prefixes. NGF and nginx images will be available from `ghcr.io`, and nginx plus will be available in GCP (`us-docker.pkg.dev/<GCP_PROJECT_ID>/nginx-gateway-fabric/nginx-plus`). These tests need to run for 4 days before releasing. The results should be committed to the main branch and then cherry-picked to the release branch.
45
45
2. Kick off the [NFR workflow](https://github.com/nginx/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. Run the workflow on the new release branch. 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. Once merged, be sure to cherry-pick the commit to the main branch as well (the original PR targets the release branch).
46
46
5. Run the [Release PR](https://github.com/nginx/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:
47
-
1. Update the version tag used in the [provisioner manifest](/tests/conformance/provisioner/provisioner.yaml) and [getting started guide](/site/content/get-started.md).
48
-
2. Update the [README](/README.md) to include information about the release.
49
-
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.
47
+
1. Update the [README](/README.md) to include information about the release.
48
+
2. Update the [changelog](/CHANGELOG.md). There is going to be a new blank section generated by the automation that needs to be adjusted accordingly.
50
49
- At the top there will be a list of all PRs that are labeled with `release-notes`.
51
50
The changelog includes only important (from the user perspective)
52
51
changes to NGF. This is in contrast with the autogenerated full changelog, which is created in the next
Copy file name to clipboardExpand all lines: docs/proposals/nginx-extensions.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -155,7 +155,7 @@ spec:
155
155
name: my-annotation
156
156
```
157
157
158
-
Infrastructure labels and annotations should be applied to all resources created in response to the Gateway. This only applies to _automated deployments_ (i.e., provisioner mode), implementations that automatically deploy the data plane based on a Gateway.
158
+
Infrastructure labels and annotations should be applied to all resources created in response to the Gateway.
159
159
Other use cases for this API are Service type, Service IP, CPU memory requests, affinity rules, and Gateway routability (public, private, and cluster).
0 commit comments