merge: #8730

8730: [Backport stable/1.3] Replace all references of develop branch r=npepinpe a=npepinpe

## Description

Replaces all the references to the develop branch in build scripts, licenses, and documentation, and refer to the new main branch.



Co-authored-by: Nicolas Pepin-Perreault <nicolas.pepin-perreault@camunda.com>

.ci/jobs/docker_zeebe.dsl

@@ -10,7 +10,7 @@ pipelineJob('zeebe-docker') {
     }
 
     parameters {
-        stringParam('BRANCH', 'develop', 'Which zeebe-io/zeebe branch to build and push?')
+        stringParam('BRANCH', 'main', 'Which branch to build and push?')
         stringParam('VERSION', '', 'Zeebe version to build the image for')
         booleanParam('IS_LATEST', false, 'Should the docker image be tagged as camunda/zeebe:latest?')
         booleanParam('PUSH', false, 'Should the docker image be pushed to docker hub?')

.ci/scripts/distribution/analyse-java.sh

@@ -22,10 +22,10 @@ else
     PROPERTIES+=("-Dsonar.branch.name=${GIT_BRANCH}")
   fi
 
-  if [ "${GIT_BRANCH}" == "develop" ]; then
+  if [ "${GIT_BRANCH}" == "main" ]; then
     TARGET_BRANCH="${GIT_BRANCH}"
   else
-    TARGET_BRANCH="develop"
+    TARGET_BRANCH="main"
     PROPERTIES+=("-Dsonar.branch.target=${TARGET_BRANCH}")
   fi
 

.ci/seed.dsl

@@ -20,9 +20,9 @@ def seedJob = job('seed-job-zeebe') {
         github 'camunda-cloud/zeebe', 'https'
         credentials 'github-cloud-zeebe-app'
       }
-      branch 'develop'
+      branch 'main'
       extensions {
-        localBranch 'develop'
+        localBranch 'main'
         pathRestriction {
           includedRegions(dslScriptPathToMonitor)
           excludedRegions('')
@@ -37,7 +37,7 @@ def seedJob = job('seed-job-zeebe') {
     }
   }
 
-  label 'develop'
+  label 'main'
   jdk '(Default)'
 
   steps {

.github/pull_request_template.md

@@ -31,7 +31,7 @@ _Not all items need to be done depending on the issue and the pull request._
 
 Code changes:
 * [ ] The changes are backwards compatibility with previous versions
-* [ ] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually.
+* [ ] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...main?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually.
 
 Testing:
 * [ ] There are unit/integration tests that verify all acceptance criterias of the issue

.github/workflows/codeql.yml

@@ -1,9 +1,9 @@
 name: "Code Scanning - Action"
 on:
   push:
-    branches: [develop]
+    branches: [main]
   pull_request:
-    branches: [develop]
+    branches: [main]
 jobs:
   CodeQL-Build:
     runs-on: ubuntu-latest

.github/workflows/golangci-lint.yml

@@ -4,7 +4,7 @@ on:
     tags:
       - v*
     branches:
-      - develop
+      - main
   pull_request:
 jobs:
   golangci:

.github/workflows/os-smoke-test.yml

@@ -2,9 +2,9 @@ name: OS Support Smoke Test
 
 on:
   push:
-    branches: [ develop ]
+    branches: [ main, staging, trying ]
   pull_request:
-    branches: [ develop ]
+    branches: [ stable/1.3 ]
 
 jobs:
   build:
@@ -54,8 +54,7 @@ jobs:
         uses: JesseTG/rm@v1.0.2
         with:
           path: /Users/runner/.m2/repository/uk/co/real-logic/sbe-tool
-
-      - name: Build with Maven
-        run: mvn -B -pl qa/integration-tests -am install -DskipTests -DskipChecks
+      - name: Build relevant modules
+        run: mvn -B -am -pl qa/integration-tests install -DskipTests -DskipChecks -T1C
       - name: Run smoke test
         run: mvn -B -pl qa/integration-tests verify -P smoke-test -DskipUTs -DskipChecks

CONTRIBUTING.md

@@ -76,14 +76,15 @@ describes:
 
 ## Starting on an issue
 
-The `develop` branch contains the current in-development state of the project. To work on an issue,
+The `main` branch contains the current in-development state of the project. To work on an issue,
 follow the following steps:
 
 1. Check that a [GitHub issue][issues] exists for the task you want to work on.
    If one does not, create one. Refer to the [issue guidelines](#github-issue-guidelines).
-1. Checkout the `develop` branch and pull the latest changes.
+1. Checkout the `main` branch and pull the latest changes.
+
    ```
-   git checkout develop
+   git checkout main
    git pull
    ```
 1. Create a new branch with the naming scheme `issueId-description`.
@@ -119,7 +120,7 @@ follow the following steps:
 Before opening your first pull request, please have a look at this [guide](https://github.com/camunda-cloud/zeebe/wiki/Pull-Requests-and-Code-Reviews#pull-requests).
 
 1. To start the review process create a new pull request on GitHub from your
-   branch to the `develop` branch. Give it a meaningful name and describe
+   branch to the `main` branch. Give it a meaningful name and describe
    your changes in the body of the pull request. Lastly add a link to the issue
    this pull request closes, i.e. by writing in the description `closes #123`
 2. Assign the pull request to one developer to review, if you are not sure who
@@ -135,11 +136,11 @@ Before opening your first pull request, please have a look at this [guide](https
     2. If no changes are requested the reviewer will initiate a merge by adding a
        comment with the content `bors merge`.
 5. When a merge is initiated, a bot will merge your branch with the latest
-   develop and run the CI on it.
+   main and run the CI on it.
     1. If everything goes well the branch is merged and deleted and the issue
        and pull request are closed.
     2. If there are merge conflicts the author of the pull request has to
-       manually rebase `develop` into the issue branch and retrigger a merge
+       manually rebase `main` into the issue branch and retrigger a merge
        attempt.
     3. If there are CI errors the author of the pull request has to check if
        they are caused by its changes and address them. If they are flaky tests

Jenkinsfile

@@ -6,14 +6,14 @@
 // https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set
 def buildName = "${env.JOB_BASE_NAME.replaceAll("%2F", "-").replaceAll("\\.", "-").take(20)}-${env.BUILD_ID}"
 
-def developBranchName = 'develop'
-def isDevelopBranch = env.BRANCH_NAME == developBranchName
-def latestStableBranchName = 'stable/1.1'
+def mainBranchName = 'main'
+def isMainBranch = env.BRANCH_NAME == mainBranchName
+def latestStableBranchName = 'stable/1.3'
 def isLatestStable = env.BRANCH_NAME == latestStableBranchName
 
-//for develop branch keep builds for 7 days to be able to analyse build errors, for all other branches, keep the last 10 builds
-def daysToKeep = isDevelopBranch ? '7' : '-1'
-def numToKeep = isDevelopBranch ? '-1' : '10'
+// for the main branch keep builds for 7 days to be able to analyse build errors, for all other branches, keep the last 10 builds
+def daysToKeep = isMainBranch ? '7' : '-1'
+def numToKeep = isMainBranch ? '-1' : '10'
 
 // single step timeouts - remember to be generous to avoid occasional slow downs, e.g. waiting to be
 // scheduled by Kubernetes, slow downloads of remote docker images, etc.
@@ -25,9 +25,9 @@ def longTimeoutMinutes = 45
 def itAgentUnstashDirectory = '.tmp/it'
 def itFlakyTestStashName = 'it-flakyTests'
 
-// the develop branch should be run at midnight to do a nightly build including QA test run
+// the main branch should be run at midnight to do a nightly build including QA test run
 // the latest stable branch is run two hour later at 01:00 AM.
-def cronTrigger = isDevelopBranch ? '0 0 * * *' : isLatestStable ? '0 2 * * *' : ''
+def cronTrigger = isMainBranch ? '0 0 * * *' : isLatestStable ? '0 2 * * *' : ''
 
 // since we report the build status to CI analytics at the very end, when the build is finished, we
 // need to share the result of the flaky test analysis between different stages, so using a global
@@ -332,7 +332,7 @@ pipeline {
                     expression { params.RUN_QA }
                     allOf {
                         anyOf {
-                            branch developBranchName
+                            branch mainBranchName
                             branch latestStableBranchName
                         }
                         triggeredBy 'TimerTrigger'
@@ -385,7 +385,7 @@ pipeline {
         }
 
         stage('Upload') {
-            when { allOf { branch developBranchName; not { triggeredBy 'TimerTrigger' } } }
+            when { allOf { branch mainBranchName; not { triggeredBy 'TimerTrigger' } } }
             steps {
                 retry(3) {
                     timeout(time: shortTimeoutMinutes, unit: 'MINUTES') {
@@ -400,7 +400,7 @@ pipeline {
 
             parallel {
                 stage('Docker') {
-                    when { branch developBranchName }
+                    when { branch mainBranchName }
 
                     environment {
                         VERSION = readMavenPom(file: 'parent/pom.xml').getVersion()
@@ -413,7 +413,7 @@ pipeline {
                                     string(name: 'BRANCH', value: env.BRANCH_NAME),
                                     string(name: 'VERSION', value: env.VERSION),
                                     booleanParam(name: 'IS_LATEST', value: false),
-                                    booleanParam(name: 'PUSH', value: isDevelopBranch)
+                                    booleanParam(name: 'PUSH', value: isMainBranch)
                                 ]
                             }
                         }
@@ -450,7 +450,7 @@ pipeline {
 
         failure {
             script {
-                if (env.BRANCH_NAME != 'develop' || agentDisconnected()) {
+                if (env.BRANCH_NAME != mainBranchName || agentDisconnected()) {
                     return
                 }
                 sendZeebeSlackMessage()
@@ -459,7 +459,7 @@ pipeline {
 
         changed {
             script {
-                if (env.BRANCH_NAME != 'develop' || agentDisconnected()) {
+                if (env.BRANCH_NAME != mainBranchName || agentDisconnected()) {
                     return
                 }
                 if (currentBuild.currentResult == 'FAILURE') {
@@ -527,9 +527,9 @@ def templatePodspec(String podspecPath, flags = [:]) {
         /* Criteria for using stable node pools:
          * - staging branch: to have smooth staging builds and avoid unnecessary retries
          * - params.RUN_QA: during QA stage the node must wait for the result. This can take several hours. Therefore a stable node is needed
-         * - env.isDevelopBranch: the core requirement is to have a stable node for nightly builds, which also rn QA (see above)
+         * - env.isMainBranch: the core requirement is to have a stable node for nightly builds, which also rn QA (see above)
          */
-        useStableNodePool: isBorsStagingBranch() || params.RUN_QA || env.isDevelopBranch
+        useStableNodePool: isBorsStagingBranch() || params.RUN_QA || env.isMainBranch
     ]
     // will merge Maps by overwriting left Map with values of the right Map
     def effectiveFlags = defaultFlags + flags

README.md

@@ -30,7 +30,7 @@ Here is a diagram illustrating the lifecycle of minor releases over a 13-month p
 
 ## Status
 
-To learn more about what we're currently working on, check the [GitHub issues](https://github.com/camunda-cloud/zeebe/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) and the [latest commits](https://github.com/camunda-cloud/zeebe/commits/develop).
+To learn more about what we're currently working on, check the [GitHub issues](https://github.com/camunda-cloud/zeebe/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) and the [latest commits](https://github.com/camunda-cloud/zeebe/commits/main).
 
 ## Helpful Links
 

benchmarks/docs/setup/prometheus-operator-values.yml

@@ -41,7 +41,7 @@ grafana:
   dashboards:
     default:
       zeebe:
-        url: https://raw.githubusercontent.com/zeebe-io/zeebe/develop/monitor/grafana/zeebe.json
+        url: https://raw.githubusercontent.com/camunda-cloud/zeebe/main/monitor/grafana/zeebe.json
   persistence:
     enabled: true
     storageClassName: ssd

createMedicCWBenchmark.sh

@@ -11,19 +11,19 @@ test -z "$(git ls-files --exclude-standard --others)" || \
 # Ensure you are on zeebe-cluster
 kubectx gke_zeebe-io_europe-west1-b_zeebe-cluster
 
-# switch do develop
-git checkout develop
+# switch do main
+git checkout main
 
 # get latest changes
 git fetch
-git pull origin develop
+git pull origin main
 
 # switch to cw branch
 git checkout medic-cw-benchmarks
 git pull origin medic-cw-benchmarks
 
 # update kw branch
-git merge develop --no-edit
+git merge main --no-edit
 git push origin medic-cw-benchmarks
 
 # create new kw image and deploy benchmark

licenses/Clarification-on-gRPC-code-generation.txt

@@ -1,6 +1,6 @@
 Clarification on gRPC Code Generation
 
-The Zeebe Gateway Protocol (API) as published https://github.com/zeebe-io/zeebe/blob/develop/gateway-protocol/src/main/proto/gateway.proto
+The Zeebe Gateway Protocol (API) as published https://github.com/zeebe-io/zeebe/blob/main/gateway-protocol/src/main/proto/gateway.proto
 is licensed under the Zeebe Community License 1.1. Using gRPC tooling to
 generate stubs for the protocol does not constitute creating a derivative work
 under the Zeebe Community License 1.1 and no licensing restrictions are imposed

parent/pom.xml

@@ -1695,7 +1695,7 @@
             <groupId>com.diffplug.spotless</groupId>
             <artifactId>spotless-maven-plugin</artifactId>
             <configuration>
-              <ratchetFrom>origin/develop</ratchetFrom>
+              <ratchetFrom>origin/main</ratchetFrom>
             </configuration>
             <executions>
               <execution>