From ab0d71e55c84a8bf961d49a30629a2af5689d60c Mon Sep 17 00:00:00 2001 From: "huish@microsoft.com" Date: Wed, 17 Apr 2024 07:09:17 +0000 Subject: [PATCH 1/6] dev branch rename --- .github/workflows/build-pr.yml | 2 +- .github/workflows/codeql.yml | 4 ++-- .github/workflows/golangci-lint.yml | 2 +- .github/workflows/high-availability.yml | 4 ++-- .github/workflows/pr-to-main.yml | 2 +- .github/workflows/quick-start.yml | 4 ++-- .github/workflows/scorecards.yml | 2 +- CONTRIBUTING.md | 10 +++++----- RELEASES.md | 3 +++ 9 files changed, 18 insertions(+), 15 deletions(-) diff --git a/.github/workflows/build-pr.yml b/.github/workflows/build-pr.yml index 245e7de74..4767a028a 100644 --- a/.github/workflows/build-pr.yml +++ b/.github/workflows/build-pr.yml @@ -5,7 +5,7 @@ on: types: [labeled] pull_request: branches: - - staging + - dev workflow_dispatch: permissions: read-all diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml index e00037e07..2ab5d620e 100644 --- a/.github/workflows/codeql.yml +++ b/.github/workflows/codeql.yml @@ -5,12 +5,12 @@ on: push: branches: - main - - staging + - dev - 1.0.0* pull_request: branches: - main - - staging + - dev - 1.0.0* schedule: - cron: '30 1 * * 0' diff --git a/.github/workflows/golangci-lint.yml b/.github/workflows/golangci-lint.yml index 44a5f084f..4c7f723e9 100644 --- a/.github/workflows/golangci-lint.yml +++ b/.github/workflows/golangci-lint.yml @@ -3,7 +3,7 @@ on: push: branches: - main - - staging + - dev - 1.0.0* pull_request: workflow_dispatch: diff --git a/.github/workflows/high-availability.yml b/.github/workflows/high-availability.yml index 03ffd5693..e72e14f95 100644 --- a/.github/workflows/high-availability.yml +++ b/.github/workflows/high-availability.yml @@ -6,13 +6,13 @@ on: pull_request: branches: - main - - staging + - dev - 1.0.0* push: branches: - 1.0.0* - main - - staging + - dev workflow_dispatch: permissions: read-all diff --git a/.github/workflows/pr-to-main.yml b/.github/workflows/pr-to-main.yml index bbcb4ca8e..078fced52 100644 --- a/.github/workflows/pr-to-main.yml +++ b/.github/workflows/pr-to-main.yml @@ -3,7 +3,7 @@ name: pr_to_main on: push: branches: - - 'staging' + - 'dev' permissions: pull-requests: write diff --git a/.github/workflows/quick-start.yml b/.github/workflows/quick-start.yml index 8fc887517..2b214d785 100644 --- a/.github/workflows/quick-start.yml +++ b/.github/workflows/quick-start.yml @@ -6,12 +6,12 @@ on: pull_request: branches: - main - - staging + - dev - 1.0.0* push: branches: - 1.0.0* - - staging + - dev - main workflow_dispatch: diff --git a/.github/workflows/scorecards.yml b/.github/workflows/scorecards.yml index b81777d0e..5efbd0777 100644 --- a/.github/workflows/scorecards.yml +++ b/.github/workflows/scorecards.yml @@ -7,7 +7,7 @@ on: push: branches: - main - - staging + - dev workflow_dispatch: permissions: read-all diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2efa7239e..af865e1ea 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,17 +14,17 @@ Welcome! We are very happy to accept community contributions to Ratify, whether If you'd like to start contributing to Ratify, you can search for issues tagged as "good first issue" [here](https://github.com/deislabs/ratify/labels/good%20first%20issue). -We use the `staging` branch as the our default branch. All ratify release are cut from the main branch. A sample PR process is outlined below: -1. Fork this repo and create your dev branch from default `staging` branch. +We use the `dev` branch as the our default branch. PRs passing the basic set of validation can be merged to the `dev` branch, we then run the full suite of validation including cloud specific tests on `dev` before changes can be merged into `main`. All ratify release are cut from the `main` branch. A sample PR process is outlined below: +1. Fork this repo and create your dev branch from default `dev` branch. 2. Create a PR against default branch 3. Maintainer approval and e2e test validation is required for completing the PR. 4. On PR complete, the `push` event will trigger an automated PR targeting the `main` branch where we run a full suite validation including cloud specific tests. 6. Manual merge is required to complete the PR. (**Please keep individual commits to maintain commit history**) If the PR contains a regression that could not pass the full validation, please revert the change to unblock others: -1. Create a new dev branch based off staging. -2. Open a revert PR against staging. -3. Follow the same process to get this PR gets merged into staging. +1. Create a new dev branch based off `dev`. +2. Open a revert PR against `dev`. +3. Follow the same process to get this PR gets merged into `dev`. 4. Work on the fix and follow the above PR process. ## Developing diff --git a/RELEASES.md b/RELEASES.md index 7f9318bd4..ed40cd3bf 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -32,6 +32,9 @@ Example pre-release versions include `v0.1.0-alpha1`, `v0.1.0-beta2`, `v0.1.0-rc 5. Copy contents from [`dev.helmfile.yaml`](dev.helmfile.yaml) to [`helmfile.yaml`](helmfile.yaml) & [`dev.high-availability.helmfile.yaml`](dev.high-availability.helmfile.yaml) to [`high-availability.helmfile.yaml`](high-availability.helmfile.yaml). You MUST update/remove values marked by comments in the files. The `dev` prefixed helmfiles are treated as staging files that are up to date with new changes on main branch. The primary `helmfile.yaml` and `high-availability.helmfile.yaml` MUST stay pinned to the current release since they are used by the quickstarts. Update `dev.helmfile.yaml` & `dev.high-availability.helmfile.yaml` ratify chart version to new release version. +6. Our `main` branch contains an extra merge commits compared to `dev` due to the PR [workflow](CONTRIBUTING.md#pull-requests), once per release, we will need to sync `dev` with the `main` branch. +Once we are looking to automate this with tracking [issue], for now we will need the following steps: + - git push origin --force main:dev ## Git Release Flow This section deals with the practical considerations of versioning in Git, this repo's version control system. See the semantic versioning specification for the scope of changes allowed for each release type. From a59f5f3cdbeaf3fb9b97f548aaad40dc84b79e3b Mon Sep 17 00:00:00 2001 From: "huish@microsoft.com" Date: Thu, 18 Apr 2024 04:27:11 +0000 Subject: [PATCH 2/6] post release --- RELEASES.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index ed40cd3bf..f8dbf95dc 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -34,7 +34,9 @@ Example pre-release versions include `v0.1.0-alpha1`, `v0.1.0-beta2`, `v0.1.0-rc 6. Our `main` branch contains an extra merge commits compared to `dev` due to the PR [workflow](CONTRIBUTING.md#pull-requests), once per release, we will need to sync `dev` with the `main` branch. Once we are looking to automate this with tracking [issue], for now we will need the following steps: - - git push origin --force main:dev + - maintainer manually disable allow force push in branch protection rule + - make sure the local main branch is up to date + - force push to dev branch, ```git push origin --force main:dev``` ## Git Release Flow This section deals with the practical considerations of versioning in Git, this repo's version control system. See the semantic versioning specification for the scope of changes allowed for each release type. @@ -63,7 +65,13 @@ Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/fil ## Post Release Activity -After a successful release, please manually trigger [quick start action](.github/quick-start.yml) to validate the quick start test is passing. Validate in the run logs that the version of ratify matches the latest released version. +1. Our `main` branch contains an extra merge commits compared to `dev` due to the PR [workflow](CONTRIBUTING.md#pull-requests), once per release, we will need to sync `dev` with the `main` branch. +Once we are looking to automate this with tracking [issue], for now we will need the following steps: + - maintainer manually disable allow force push in branch protection rule + - make sure the local main branch is up to date + - force push to dev branch, ```git push origin --force main:dev``` + +2. After a successful release, please manually trigger [quick start action](.github/quick-start.yml) to validate the quick start test is passing. Validate in the run logs that the version of ratify matches the latest released version. ### Weekly Dev Release From 1f3a2bad3b69ace97176fdb6de1d97f6eb0a9234 Mon Sep 17 00:00:00 2001 From: Susan Shi Date: Tue, 7 May 2024 14:45:04 +1000 Subject: [PATCH 3/6] Update RELEASES.md Signed-off-by: Susan Shi --- RELEASES.md | 41 +++++++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index f8dbf95dc..62d2cc273 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -9,6 +9,7 @@ The specification release process was created using content and verbiage from th * [ORAS Artifact Specification Releases](https://github.com/oras-project/artifacts-spec/blob/main/RELEASES.md) * [ORAS Developer Guide](https://github.com/oras-project/oras-www/blob/main/docs/CLI/5_developer_guide.md) * [Mystikos Release Management](https://github.com/deislabs/mystikos/blob/main/doc/releasing.md) +* [Gatekeeper Release Management](https://github.com/open-policy-agent/gatekeeper/blob/8f5201f0f48d50cc14153d100172689f03aa5f39/docs/Release_Management.md) ## Versioning @@ -32,22 +33,19 @@ Example pre-release versions include `v0.1.0-alpha1`, `v0.1.0-beta2`, `v0.1.0-rc 5. Copy contents from [`dev.helmfile.yaml`](dev.helmfile.yaml) to [`helmfile.yaml`](helmfile.yaml) & [`dev.high-availability.helmfile.yaml`](dev.high-availability.helmfile.yaml) to [`high-availability.helmfile.yaml`](high-availability.helmfile.yaml). You MUST update/remove values marked by comments in the files. The `dev` prefixed helmfiles are treated as staging files that are up to date with new changes on main branch. The primary `helmfile.yaml` and `high-availability.helmfile.yaml` MUST stay pinned to the current release since they are used by the quickstarts. Update `dev.helmfile.yaml` & `dev.high-availability.helmfile.yaml` ratify chart version to new release version. -6. Our `main` branch contains an extra merge commits compared to `dev` due to the PR [workflow](CONTRIBUTING.md#pull-requests), once per release, we will need to sync `dev` with the `main` branch. -Once we are looking to automate this with tracking [issue], for now we will need the following steps: - - maintainer manually disable allow force push in branch protection rule - - make sure the local main branch is up to date - - force push to dev branch, ```git push origin --force main:dev``` ## Git Release Flow This section deals with the practical considerations of versioning in Git, this repo's version control system. See the semantic versioning specification for the scope of changes allowed for each release type. +All releases will be of the form _vX.Y.Z_ where X is the major version, Y is the minor version and Z is the patch version. + ### Patch releases -When a patch release is required, the patch commits should be merged with the `main` branch when ready. Then a new branch should be created with the patch version incremented and optional pre-release specifiers. For example if the previous release was `v0.1.0`, the branch should be named `v0.1.1` and can optionally be suffixed with a pre-release (e.g. `v0.1.1-rc1`). The limited nature of fixes in a patch release should mean pre-releases can often be omitted. +Applicable fixes, including security fixes, may be backported to supported releases, depending on severity and feasibility. Patch release are cut from branch `release-X.Y`. Commits can be cherry-picked from `main`, changes should be merged into latest supported minor release-X.Y branches once required PR requirements are met. ### Minor releases -When a minor release is required, the release commits should be merged with the `main` branch when ready. Then a new branch should be created with the minor version incremented and optional pre-release specifiers. For example if the previous release was `v0.1.1`, the branch should be named `v0.2.0` and can optionally be suffixed with a pre-release (e.g. `v0.2.0-beta1`). Pre-releases will be more common will be more common with minor releases. +When a minor release is required, the release commits should be merged with the `main` branch when ready. A new branch `release-X.Y` will be created. Pre-releases will be more common will be more common with minor releases. Required changes for the minor release should be PRed directly to the to the `release-X.Y` branch, the change will then be ported back to `main`. ### Major releases @@ -55,7 +53,9 @@ When a major release is required, the release commits should be merged with the ### Tag and Release -Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/files) to update the chart value. When the release branch is ready, a tag should be pushed with a name matching the branch name, e.g. `git tag v0.1.0-alpha1` and `git push --tags`. This will trigger a [Goreleaser](https://goreleaser.com/) action that will build the binaries and creates a [GitHub release](https://help.github.com/articles/creating-releases/): +**X.Y.Z** refers to the version (git tag) of Gatekeeper that is released. This is the version of the Ratify image and the Chart version. + +Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/files) to update the chart value. When the `release-X.Y` branch is ready, a tag **X.Y.Z** should be pushed. e.g. `git tag v1.1.1` and `git push --tags`. This will trigger a [Goreleaser](https://goreleaser.com/) action that will build the binaries and creates a [GitHub release](https://help.github.com/articles/creating-releases/): * The release will be marked as a draft to allow an final editing before publishing. * The release notes and other fields can edited after the action completes. The description can be in Markdown. @@ -63,15 +63,24 @@ Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/fil * The pre-built binaries are built from commit at the head of the release branch. * The files are named `ratify_--__` with `.zip` files for Windows and `.tar.gz` for all others. -## Post Release Activity +## Supported Releases + +Applicable fixes, including security fixes, may be cherry-picked into the release branch, depending on severity and feasibility. Patch releases are cut from that branch as needed. + +We expect users to stay reasonably up-to-date with the versions of Gatekeeper they use in production, but understand that it may take time to upgrade. We expect users to be running approximately the latest patch release of a given minor release and encourage users to upgrade as soon as possible. -1. Our `main` branch contains an extra merge commits compared to `dev` due to the PR [workflow](CONTRIBUTING.md#pull-requests), once per release, we will need to sync `dev` with the `main` branch. -Once we are looking to automate this with tracking [issue], for now we will need the following steps: - - maintainer manually disable allow force push in branch protection rule - - make sure the local main branch is up to date - - force push to dev branch, ```git push origin --force main:dev``` +We expect to "support" n (current). "Support" means we expect users to be running that version in production. For example, when v1.2 comes out, v1.1 will no longer be supported for patches, and we encourage users to upgrade to a supported version as soon in 5minas possible. + +## Supported Kubernetes and Gatekeeper Versions + +Gatekeeper is assumed to be compatible with the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/). + +For example, if Gatekeeper _supported_ versions are v3.7 and v3.8, and Kubernetes _supported_ versions are v1.22, v1.23, v1.24, then all supported Gatekeeper versions (v3.7, v3.8) are assumed to be compatible with all supported Kubernetes versions (v1.22, v1.23, v1.24). If Kubernetes v1.25 is released later, then Gatekeeper v3.7 and v3.8 will be assumed to be compatible with v1.25 if those Gatekeeper versions are still supported at that time. + +If you choose to use Gatekeeper with a version of Kubernetes that it does not support, you are using it at your own risk. +## Post Release Activity -2. After a successful release, please manually trigger [quick start action](.github/quick-start.yml) to validate the quick start test is passing. Validate in the run logs that the version of ratify matches the latest released version. +After a successful release, please manually trigger [quick start action](.github/quick-start.yml) to validate the quick start test is passing. Validate in the run logs that the version of ratify matches the latest released version. ### Weekly Dev Release @@ -101,4 +110,4 @@ helm install ratify \ --set image.tag=dev.. --set-file notationCerts[0]=./test/testdata/notation.crt ``` -NOTE: the tag field is the only value that will change when updating to newer dev build images \ No newline at end of file +NOTE: the tag field is the only value that will change when updating to newer dev build images From 20392c5d0f71fa9d800420582e5e8befbb1f9717 Mon Sep 17 00:00:00 2001 From: "huish@microsoft.com" Date: Tue, 7 May 2024 08:18:56 +0000 Subject: [PATCH 4/6] update supported version --- RELEASES.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 62d2cc273..65f63fb4d 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -45,7 +45,7 @@ Applicable fixes, including security fixes, may be backported to supported relea ### Minor releases -When a minor release is required, the release commits should be merged with the `main` branch when ready. A new branch `release-X.Y` will be created. Pre-releases will be more common will be more common with minor releases. Required changes for the minor release should be PRed directly to the to the `release-X.Y` branch, the change will then be ported back to `main`. +When a minor release is required, the release commits should be merged with the `main` branch when ready. Alpha and Beta releases will be cut from the main branch, for RC and stable releases a new branch `release-X.Y` will be created. Required changes for the minor release should be PRed to the `dev` branch, the change will then be cherry picked to `release-X.Y` from `main`. ### Major releases @@ -64,20 +64,16 @@ Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/fil * The files are named `ratify_--__` with `.zip` files for Windows and `.tar.gz` for all others. ## Supported Releases - Applicable fixes, including security fixes, may be cherry-picked into the release branch, depending on severity and feasibility. Patch releases are cut from that branch as needed. -We expect users to stay reasonably up-to-date with the versions of Gatekeeper they use in production, but understand that it may take time to upgrade. We expect users to be running approximately the latest patch release of a given minor release and encourage users to upgrade as soon as possible. - -We expect to "support" n (current). "Support" means we expect users to be running that version in production. For example, when v1.2 comes out, v1.1 will no longer be supported for patches, and we encourage users to upgrade to a supported version as soon in 5minas possible. +We expect to "support" n (current). "Support" means we expect users to be running that version in production. For example, when v1.2 comes out, v1.1 will no longer be supported for patches, and we encourage users to upgrade to a supported version as soon as possible. ## Supported Kubernetes and Gatekeeper Versions -Gatekeeper is assumed to be compatible with the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/). +Ratify is assumed to be compatible with currently supported GateKeeper versions and the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/). -For example, if Gatekeeper _supported_ versions are v3.7 and v3.8, and Kubernetes _supported_ versions are v1.22, v1.23, v1.24, then all supported Gatekeeper versions (v3.7, v3.8) are assumed to be compatible with all supported Kubernetes versions (v1.22, v1.23, v1.24). If Kubernetes v1.25 is released later, then Gatekeeper v3.7 and v3.8 will be assumed to be compatible with v1.25 if those Gatekeeper versions are still supported at that time. +For example, if Gatekeeper _supported_ versions are v3.7 and v3.8, and Kubernetes _supported_ versions are v1.22, v1.23, v1.24, then current version of Ratify (v1.1) are assumed to be compatible with all supported Kubernetes versions (v1.22, v1.23, v1.24). -If you choose to use Gatekeeper with a version of Kubernetes that it does not support, you are using it at your own risk. ## Post Release Activity After a successful release, please manually trigger [quick start action](.github/quick-start.yml) to validate the quick start test is passing. Validate in the run logs that the version of ratify matches the latest released version. From 74f2344e485c90f206df7711d1d846c41d628b4a Mon Sep 17 00:00:00 2001 From: "huish@microsoft.com" Date: Wed, 8 May 2024 04:30:17 +0000 Subject: [PATCH 5/6] supported version --- RELEASES.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 65f63fb4d..123425264 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -45,11 +45,14 @@ Applicable fixes, including security fixes, may be backported to supported relea ### Minor releases -When a minor release is required, the release commits should be merged with the `main` branch when ready. Alpha and Beta releases will be cut from the main branch, for RC and stable releases a new branch `release-X.Y` will be created. Required changes for the minor release should be PRed to the `dev` branch, the change will then be cherry picked to `release-X.Y` from `main`. +When a minor release is required, the release commits should be merged with the `main` branch when ready. + + - Alpha and Beta releases will be cut from the main branch. + - For RC and stable releases, a new branch `release-X.Y` will be created from `main`. Required changes for the minor release should be PRed to the `dev` branch, the change will then be cherry picked to `release-X.Y` from `main`. ### Major releases -When a major release is required, the release commits should be merged with the `main` branch when ready. Then a new branch should be created with the major version incremented and optional pre-release specifiers. For example if the previous release was `v1.1.1`, the branch should be named `v2.0.0` and can optionally be suffixed with a pre-release (e.g. `v2.0.0-alpha1`). Major versions will usually require multiple pre-release versions. +When a major release is required, the release commits should be merged with the `main` branch when ready. Major versions will usually require multiple pre-release versions. Similar to minor releases, the new branch should be created for the RC and stable release. ### Tag and Release @@ -70,9 +73,9 @@ We expect to "support" n (current). "Support" means we expect users to be runnin ## Supported Kubernetes and Gatekeeper Versions -Ratify is assumed to be compatible with currently supported GateKeeper versions and the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/). +Ratify is assumed to be compatible with [GateKeeper Supported Versions](https://github.com/open-policy-agent/gatekeeper/blob/master/docs/Release_Management.md#supported-releases) and the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/). -For example, if Gatekeeper _supported_ versions are v3.7 and v3.8, and Kubernetes _supported_ versions are v1.22, v1.23, v1.24, then current version of Ratify (v1.1) are assumed to be compatible with all supported Kubernetes versions (v1.22, v1.23, v1.24). +For example, if Gatekeeper _supported_ versions are v3.13 and v3.14, and Kubernetes _supported_ versions are v1.27, v1.28, v1.29, then current version of Ratify (v1.1) are assumed to be compatible with all supported Kubernetes versions (v1.27, v1.28, v1.29) and Gatekeeper version(v3.13, v3.14). ## Post Release Activity From 24e562397c1df8a3c52a16947d92ed3cc1808a71 Mon Sep 17 00:00:00 2001 From: "huish@microsoft.com" Date: Wed, 12 Jun 2024 05:16:42 +0000 Subject: [PATCH 6/6] update to new repo path --- RELEASES.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/RELEASES.md b/RELEASES.md index 123425264..739401f67 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -27,9 +27,9 @@ Example pre-release versions include `v0.1.0-alpha1`, `v0.1.0-beta2`, `v0.1.0-rc 2. If the format of the data returned for [external data calls](docs/reference/verification-result-version.md) has changed, validate change is also reflected in [`httpserver/types.go`](httpserver/types.go). -3. Delete all dev images generated since the previous release under the `ratify-dev` and `ratify-crds-dev` [packages](https://github.com/orgs/deislabs/packages?repo_name=ratify). Each dev image tag is prefixed with `dev` followed by the date of creation and then the abbreviated 7 character commit SHA (e.g a build generated on March 8, 2023 from main branch with commit SHA `4cf98388ef33c587ef86b82e05cb0f7de2da2ea8` would be tagged `dev.20230308.4cf9838`). The most recent images are also tagged with a rolling tag `latest`. +3. Delete all dev images generated since the previous release under the `ratify-dev` and `ratify-crds-dev` [packages](https://github.com/orgs/ratify-project/packages?repo_name=ratify). Each dev image tag is prefixed with `dev` followed by the date of creation and then the abbreviated 7 character commit SHA (e.g a build generated on March 8, 2023 from main branch with commit SHA `4cf98388ef33c587ef86b82e05cb0f7de2da2ea8` would be tagged `dev.20230308.4cf9838`). The most recent images are also tagged with a rolling tag `latest`. -4. Delete all dev helm charts since the previous release under the `ratify-chart-dev/ratify` [packages](https://github.com/orgs/deislabs/packages?repo_name=ratify). Each helm chart is published with a semantic version compatible tag `0-dev` followed by the date of creation and then the abbreviated 7 character commit SHA (e.g a chart generated on March 8, 2023 from main branch with commit SHA `4cf98388ef33c587ef86b82e05cb0f7de2da2ea8` would be tagged `0-dev.20230308.4cf9838`). The most recent dev chart is also tagged with the rolling tag `0-dev`. +4. Delete all dev helm charts since the previous release under the `ratify-chart-dev/ratify` [packages](https://github.com/orgs/ratify-project/packages?repo_name=ratify). Each helm chart is published with a semantic version compatible tag `0-dev` followed by the date of creation and then the abbreviated 7 character commit SHA (e.g a chart generated on March 8, 2023 from main branch with commit SHA `4cf98388ef33c587ef86b82e05cb0f7de2da2ea8` would be tagged `0-dev.20230308.4cf9838`). The most recent dev chart is also tagged with the rolling tag `0-dev`. 5. Copy contents from [`dev.helmfile.yaml`](dev.helmfile.yaml) to [`helmfile.yaml`](helmfile.yaml) & [`dev.high-availability.helmfile.yaml`](dev.high-availability.helmfile.yaml) to [`high-availability.helmfile.yaml`](high-availability.helmfile.yaml). You MUST update/remove values marked by comments in the files. The `dev` prefixed helmfiles are treated as staging files that are up to date with new changes on main branch. The primary `helmfile.yaml` and `high-availability.helmfile.yaml` MUST stay pinned to the current release since they are used by the quickstarts. Update `dev.helmfile.yaml` & `dev.high-availability.helmfile.yaml` ratify chart version to new release version. @@ -56,9 +56,7 @@ When a major release is required, the release commits should be merged with the ### Tag and Release -**X.Y.Z** refers to the version (git tag) of Gatekeeper that is released. This is the version of the Ratify image and the Chart version. - -Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/files) to update the chart value. When the `release-X.Y` branch is ready, a tag **X.Y.Z** should be pushed. e.g. `git tag v1.1.1` and `git push --tags`. This will trigger a [Goreleaser](https://goreleaser.com/) action that will build the binaries and creates a [GitHub release](https://help.github.com/articles/creating-releases/): +**X.Y.Z** refers to the version (git tag) of Ratify that is released. Prepare the release with a [PR](https://github.com/deislabs/ratify/pull/1031/files) to update the chart value. When the `release-X.Y` branch is ready, a tag **X.Y.Z** should be pushed. e.g. `git tag v1.1.1` and `git push --tags`. This will trigger a [Goreleaser](https://goreleaser.com/) action that will build the binaries and creates a [GitHub release](https://help.github.com/articles/creating-releases/): * The release will be marked as a draft to allow an final editing before publishing. * The release notes and other fields can edited after the action completes. The description can be in Markdown. @@ -75,7 +73,7 @@ We expect to "support" n (current). "Support" means we expect users to be runnin Ratify is assumed to be compatible with [GateKeeper Supported Versions](https://github.com/open-policy-agent/gatekeeper/blob/master/docs/Release_Management.md#supported-releases) and the [current Kubernetes Supported Versions](https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches) per [Kubernetes Supported Versions policy](https://kubernetes.io/releases/version-skew-policy/). -For example, if Gatekeeper _supported_ versions are v3.13 and v3.14, and Kubernetes _supported_ versions are v1.27, v1.28, v1.29, then current version of Ratify (v1.1) are assumed to be compatible with all supported Kubernetes versions (v1.27, v1.28, v1.29) and Gatekeeper version(v3.13, v3.14). +For example, if Gatekeeper _supported_ versions are v3.13 and v3.14, and Kubernetes _supported_ versions are v1.28, v1.29, then current version of Ratify (v1.2) are assumed to be compatible with all supported Kubernetes versions (v1.28, v1.29) and Gatekeeper version(v3.13, v3.14). ## Post Release Activity @@ -84,7 +82,7 @@ After a successful release, please manually trigger [quick start action](.github ### Weekly Dev Release #### Publishing Guidelines -- Ratify is configured to generate and publish dev build images based on the schedule [here](https://github.com/deislabs/ratify/blob/main/.github/workflows/publish-package.yml#L8). +- Ratify is configured to generate and publish dev build images based on the schedule [here](https://github.com/ratify-project/ratify/blob/main/.github/workflows/publish-package.yml#L8). - Contributors MUST select the `Helm Chart Change` option under the `Type of Change` section if there is ANY update to the helm chart that is required for proposed changes in PR. - Maintainers MUST manually trigger the "Publish Package" workflow after merging any PR that indicates `Helm Chart Change` - Go to the `Actions` tab for the Ratify repository @@ -98,14 +96,14 @@ After a successful release, please manually trigger [quick start action](.github - Once issue is created, post in the `#ratify` slack channel and tag the maintainers - Maintainers should acknowledge request by approving/denying request as a follow up comment #### How to use a dev build -1. The `ratify` image and `ratify-crds` image for dev builds exist as separate packages on Github [here](https://github.com/deislabs/ratify/pkgs/container/ratify-dev) and [here](https://github.com/deislabs/ratify/pkgs/container/ratify-crds-dev). +1. The `ratify` image and `ratify-crds` image for dev builds exist as separate packages on Github [here](https://github.com/ratify-project/ratify/pkgs/container/ratify-dev) and [here](https://github.com/ratify-project/ratify/pkgs/container/ratify-crds-dev). 2. the `repository` `crdRepository` and `tag` fields must be updated in the helm chart to point to dev build instead of last released build. Please set the tag to be latest tag found at the corresponding `-dev` suffixed package. An example install command scaffold: ``` helm install ratify \ ./charts/ratify --atomic \ --namespace gatekeeper-system \ - --set image.repository=ghcr.io/deislabs/ratify-dev - --set image.crdRepository=ghcr.io/deislabs/ratify-crds-dev + --set image.repository=ghcr.io/ratify-project/ratify-dev + --set image.crdRepository=ghcr.io/ratify-project/ratify-crds-dev --set image.tag=dev.. --set-file notationCerts[0]=./test/testdata/notation.crt ```