diff --git a/.github/workflows/lint.yaml b/.github/workflows/lint.yaml index 3550b974..06f2152f 100644 --- a/.github/workflows/lint.yaml +++ b/.github/workflows/lint.yaml @@ -3,7 +3,7 @@ name: Lint on: push: branches: - - master + - main pull_request: jobs: diff --git a/.github/workflows/main.yaml b/.github/workflows/main.yaml index 2dd7bb90..6fb67d07 100644 --- a/.github/workflows/main.yaml +++ b/.github/workflows/main.yaml @@ -3,7 +3,7 @@ name: Tekton Tasks Tests on: push: branches: - - master + - main pull_request: env: diff --git a/docs/comparison-pipelines-as-code.adoc b/docs/comparison-pipelines-as-code.adoc index 4b3085e9..315a6da4 100644 --- a/docs/comparison-pipelines-as-code.adoc +++ b/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. diff --git a/docs/design/README.md b/docs/design/README.md index 2c24a940..73db9903 100644 --- a/docs/design/README.md +++ b/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`. diff --git a/docs/design/software-architecture.adoc b/docs/design/software-architecture.adoc index c0bbf23b..1e65ea82 100644 --- a/docs/design/software-architecture.adoc +++ b/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 diff --git a/docs/introduction.adoc b/docs/introduction.adoc index 77408208..9ece80c7 100644 --- a/docs/introduction.adoc +++ b/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. diff --git a/docs/releasing.adoc b/docs/releasing.adoc index 967c8851..a00e6b07 100644 --- a/docs/releasing.adoc +++ b/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.