Switch to main branch

.github/workflows/lint.yaml

@@ -3,7 +3,7 @@ name: Lint
 on:
   push:
     branches:
-      - master
+      - main
   pull_request:
 
 jobs:

.github/workflows/main.yaml

@@ -3,7 +3,7 @@ name: Tekton Tasks Tests
 on:
   push:
     branches:
-      - master
+      - main
   pull_request:
 
 env:

docs/comparison-pipelines-as-code.adoc

@@ -12,11 +12,11 @@ The following details some similarities and differences between ODS Pipeline and
 ## Differences
 
 * ODS Pipeline only works with Bitbucket Server, whereas Pipelines-as-Code works with Gitlab and GitHub as well
-* Pipelines-as-Code is installed as part of OpenShift Pipelines, whereas ODS Pipeline is link:https://github.com/opendevstack/ods-pipeline/blob/master/docs/installation.adoc#installation-instructions[offered as a Helm chart]. ODS Pipeline does not use any CRDs which means it can be installed without being cluster admin.
-* For Pipelines-as-Code, the definition of a pipeline run is a full `PipelineRun` YAML resource. ODS Pipeline cuts boilerplate by allowing to specify only the link:https://github.com/opendevstack/ods-pipeline/blob/master/docs/ods-configuration.adoc#configuring-pipeline-tasks[tasks of the pipeline to run].
-* ODS Pipeline comes with opinionated link:https://github.com/opendevstack/ods-pipeline/blob/master/docs/task-start.adoc[start] and link:https://github.com/opendevstack/ods-pipeline/blob/master/docs/task-finish.adoc[finish] tasks that do quite some plumbing (Git clone, setting Bitbucket status, interaction with Nexus etc.). These tasks are automatically added to each pipeline run.
-* ODS Pipeline allows to link:https://github.com/opendevstack/ods-pipeline/blob/master/docs/ods-configuration.adoc#configuring-pipeline-triggers[configure task parameters based on triggers], e.g. allowing to have the same pipeline executed for different branches, but with different parameters.
+* Pipelines-as-Code is installed as part of OpenShift Pipelines, whereas ODS Pipeline is link:https://github.com/opendevstack/ods-pipeline/blob/main/docs/installation.adoc#installation-instructions[offered as a Helm chart]. ODS Pipeline does not use any CRDs which means it can be installed without being cluster admin.
+* For Pipelines-as-Code, the definition of a pipeline run is a full `PipelineRun` YAML resource. ODS Pipeline cuts boilerplate by allowing to specify only the link:https://github.com/opendevstack/ods-pipeline/blob/main/docs/ods-configuration.adoc#configuring-pipeline-tasks[tasks of the pipeline to run].
+* ODS Pipeline comes with opinionated link:https://github.com/opendevstack/ods-pipeline/blob/main/docs/task-start.adoc[start] and link:https://github.com/opendevstack/ods-pipeline/blob/main/docs/task-finish.adoc[finish] tasks that do quite some plumbing (Git clone, setting Bitbucket status, interaction with Nexus etc.). These tasks are automatically added to each pipeline run.
+* ODS Pipeline allows to link:https://github.com/opendevstack/ods-pipeline/blob/main/docs/ods-configuration.adoc#configuring-pipeline-triggers[configure task parameters based on triggers], e.g. allowing to have the same pipeline executed for different branches, but with different parameters.
 * ODS Pipeline ships with a built-in concept of "pipeline run artifacts", which allow to retain information about tasks (e.g. executed unit tests, SBOM files etc) in Nexus.
-* Based on the "pipeline run artifacts" concept, ODS Pipeline offers a turnkey solution to promote applications from one environment to the other. This functionality is implemented in the start and finish tasks. Users can configure a promotion chain (e.g. DEV -> QA -> PROD) which then moves built artifacts such as container images from one environment to the other. See the link:https://github.com/opendevstack/ods-pipeline/blob/master/docs/example-project.adoc[Example Project] for more details.
+* Based on the "pipeline run artifacts" concept, ODS Pipeline offers a turnkey solution to promote applications from one environment to the other. This functionality is implemented in the start and finish tasks. Users can configure a promotion chain (e.g. DEV -> QA -> PROD) which then moves built artifacts such as container images from one environment to the other. See the link:https://github.com/opendevstack/ods-pipeline/blob/main/docs/example-project.adoc[Example Project] for more details.
 * ODS Pipeline provides two Go packages, link:https://pkg.go.dev/github.com/opendevstack/ods-pipeline/pkg/tektontaskrun[tektontaskrun] and link:https://pkg.go.dev/github.com/opendevstack/ods-pipeline/pkg/odstasktest[odstasktest], for testing (any) Tekton tasks in a KinD cluster.
 * Pipelines-as-Code allows to link:https://pipelinesascode.com/docs/guide/repositorycrd/#concurrency[configure a concurrency limit] per repository, while ODS Pipeline has a link:https://github.com/opendevstack/ods-pipeline/issues/534[fixed limit of one pipeline run] per repository at a time.

docs/design/README.md

@@ -11,7 +11,7 @@ asciidoctor-pdf -a allow-uri-read software-architecture.adoc
 Best to include like this:
 
 ```
-image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/master/docs/trigger_architecture.puml[Architecture]
+image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/main/docs/trigger_architecture.puml[Architecture]
 ```
 
 That way the images are rendered in GitHub. To render them in PDF, ensure you set `-a allow-uri-read`.

docs/design/software-architecture.adoc

@@ -28,15 +28,15 @@ N/A
 
 ODS Pipeline is used alongside an existing ODS Core installation. It is a replacement for Jenkins as the CI/CD engine. The following diagram illustrates the relationship of ODS Pipeline to external systems:
 
-image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/master/docs/architecture/system-context.puml[System Context]
+image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/main/docs/architecture/system-context.puml[System Context]
 
 The following diagram illustrates in more detail how the various components interact:
 
-image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/master/docs/architecture/container-system.puml[Software System]
+image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/main/docs/architecture/container-system.puml[Software System]
 
 As the diagram above shows, the ODS Pipeline installation is made up of one container installed by project admins (once per project) containing configuration (config maps and secrets), the pipeline manager and task resources (Tekton task definitions and their referenced images). The following diagram shows more detail about the installation:
 
-image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/master/docs/architecture/component-namespaced-installation.puml[Namespaced Installation]
+image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/main/docs/architecture/component-namespaced-installation.puml[Namespaced Installation]
 
 === Interfaces
 

docs/introduction.adoc

@@ -73,7 +73,7 @@ You can see that it defines three tasks, `build`, `package` and `deploy`, which
 
 In order to create pipeline runs based on these task definitions whenever there is a push to Bitbucket, a webhook setting must be created for the repository. This webhook must point to a route connected to the ODS pipeline manager in OpenShift. When the webhook fires, a payload with information about the pushed commit is sent. The ODS pipeline manager first checks the authenticity of the request (did the request really originate from a push in the Bitbucket repository?). Then, it retrieves the `ods.yaml` file from the Git repository/ref identified in the payload, and reads the pipeline configuration. Based on the tasks defined there, it assembles a new Tekton pipeline run. Finally, the ODS pipeline manager starts the pipeline run, passing parameter values extracted from the webhook event payload. The following illustrates this flow:
 
-image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/master/docs/architecture/trigger_architecture.puml[Trigger Architecture]
+image::http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/opendevstack/ods-pipeline/main/docs/architecture/trigger_architecture.puml[Trigger Architecture]
 
 With the above in place, you do not need to manage pipeline runs manually. Every repository with an `ods.yaml` file and a webhook configuration automatically manages and triggers pipeline runs based on the defined tasks.
 

docs/releasing.adoc

@@ -13,7 +13,7 @@ ODS pipeline follows https://semver.org[Semantic Versioning 2.0.0]. This means b
 Ensure that all issues with the milestone of the release are resolved (or re-assign the issues to a future release). Further, run `govulncheck ./...` locally to check if there are any vulnerabilities that need to be fixed before the release. For more information on `govulncheck`, see https://go.dev/blog/vuln.
 
 === Preparing the release
-The current version is hardcoded in a few places across the repository. All of these places must be updated for a release (search for `X.Y.Z`, ignoring the `test` directory). After the version numbers have been updated, mark the new version as released in the changelog and update the readme file. Commit the changes and push to the `master` branch.
+The current version is hardcoded in a few places across the repository. All of these places must be updated for a release (search for `X.Y.Z`, ignoring the `test` directory). After the version numbers have been updated, mark the new version as released in the changelog and update the readme file. Commit the changes and push to the `main` branch.
 
 === Publishing the release
 Draft a new GitHub release, creating a new tag in the process (e.g. `v0.2.0`). The description should be like this:
@@ -22,9 +22,9 @@ Draft a new GitHub release, creating a new tag in the process (e.g. `v0.2.0`). T
 ----
 < Note highlights of the release and any breaking changes >
 
-For all changes and more details, please see the [changelog](https://github.com/opendevstack/ods-pipeline/blob/master/CHANGELOG.md#< Add anchor of the released version>).
+For all changes and more details, please see the [changelog](https://github.com/opendevstack/ods-pipeline/blob/main/CHANGELOG.md#< Add anchor of the released version>).
 
-To update your ODS pipeline installation, refer to the [update instructions](https://github.com/opendevstack/ods-pipeline/blob/master/docs/installation.adoc#updating).
+To update your ODS pipeline installation, refer to the [update instructions](https://github.com/opendevstack/ods-pipeline/blob/main/docs/installation.adoc#updating).
 ----
 
 NOTE: When a Git tag is created, container images are built automatically and pushed to ghcr.io.