From 71f4ab7a2ed194af0d8f54e257bbe7360965f614 Mon Sep 17 00:00:00 2001 From: Susan Shi Date: Thu, 18 Apr 2024 18:20:15 +1000 Subject: [PATCH] fix: rename staging to dev branch (#1401) Co-authored-by: Binbin Li --- .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 | 13 ++++++++++++- 9 files changed, 27 insertions(+), 16 deletions(-) diff --git a/.github/workflows/build-pr.yml b/.github/workflows/build-pr.yml index bbfd958320..a25c8974b2 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 e00037e070..2ab5d620eb 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 44a5f084f9..4c7f723e9b 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 03ffd56932..e72e14f955 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 6ce008c901..518a1fd93d 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 8fc8875177..2b214d785a 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 b81777d0ed..5efbd07774 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 5a1d8b12e9..8df9532157 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 6487a911c7..ff5c82cddb 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -32,6 +32,11 @@ 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. @@ -60,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