diff --git a/.github/workflows/build-pr.yml b/.github/workflows/build-pr.yml index bbfd95832..a25c8974b 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 6ce008c90..518a1fd93 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 5a1d8b12e..8df953215 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 6487a911c..ff5c82cdd 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