fix: rename staging to dev branch (#1401)

Co-authored-by: Binbin Li <[email protected]>

.github/workflows/build-pr.yml

@@ -5,7 +5,7 @@ on:
     types: [labeled]
   pull_request:
     branches:
-      - staging
+      - dev
   workflow_dispatch:
 
 permissions: read-all

.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'

.github/workflows/golangci-lint.yml

@@ -3,7 +3,7 @@ on:
   push:
     branches:
       - main
-      - staging
+      - dev
       - 1.0.0*
   pull_request:
   workflow_dispatch:

.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

.github/workflows/pr-to-main.yml

@@ -3,7 +3,7 @@ name: pr_to_main
 on:
   push:
     branches:
-      - 'staging'
+      - 'dev'
 
 permissions:
   pull-requests: write

.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:
 

.github/workflows/scorecards.yml

@@ -7,7 +7,7 @@ on:
   push:
     branches:
       - main
-      - staging
+      - dev
   workflow_dispatch:
 
 permissions: read-all

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

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