Releases: saritasa-nest/saritasa-devops-helm-charts
saritasa-tekton-apps-2.1.6
A Helm chart for tekton apps (rbac, eventlistener) Implements: - dynamic records for eventlistener - PVCs - RBAC - configmaps for each app - triggerbindings for each app - kubernetes job to make sure the PVCs are bound and argocd marks the app as healthy - argocd project for each app - argocd application for each app component - argocd notifications for each app project ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then declare dynamic list of projects (and associated components of that project like backend, api, frontend, etc) that would be dynamically added into the tekton's eventlistener manifest. Each component should be a separate git repository. yaml --- apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-apps namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "41" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-apps helm: values: | environment: staging gitBranchPrefixes: - staging storageClassName: gp3 nodeSelector: ops: 'true' aws: region: "us-west-2" dns: staging.site.com defaultRegistry: xxx.dkr.ecr.us-west-2.amazonaws.com argocd: server: deploy.staging.site.com trigger: enableWebhookSecret: true labels: builder: tekton apps: - project: vp enabled: true argocd: labels: created-by: xxx ops-main: xxx ops-secondary: xxx pm: xxx tm: xxx namespace: prod notifications: annotations: # In rocks/cloud cluster use slack-token integration: notifications.argoproj.io/subscribe.on-health-degraded.slack: project-vp; project-vp-alarms notifications.argoproj.io/subscribe.on-sync-failed.slack: project-vp-ci; project-vp-alarms notifications.argoproj.io/subscribe.on-sync-status-unknown.slack: project-vp; project-vp-alarms notifications.argoproj.io/subscribe.on-deployed.slack: project-vp-ci # In staging/prod client cluster use webhook integration: notifications.argoproj.io/subscribe.on-health-degraded.project-webhook: enabled mailList: [email protected] devopsMailList: [email protected] jiraURL: https://site.atlassian.net/browse/vp tektonURL: https://tekton.staging.site.com/#/namespaces/ci/pipelineruns slack: client-vp-ci kubernetesRepository: name: vp-kubernetes-aws branch: main url: [email protected]:org-name/vp-kubernetes-aws.git components: - name: backend repository: vp-backend pipeline: buildpack-django-build-pipeline applicationURL: https://api.staging.site.com argocd: syncWave: 220 labels: team: devteam any-label-name: label-value tekton: workspacePVC: 15Gi buildpacksPVC: 25Gi eventlistener: template: buildpack-django-build-pipeline-trigger-template triggerBinding: - name: docker_registry_repository value: xxx.dkr.ecr.us-west-2.amazonaws.com/vp/staging/backend - name: buildpack_builder_image value: xxx.dkr.ecr.us-west-2.amazonaws.com/vp/staging/buildpacks/google/builder:v1 - name: buildpack_runner_image value: xxx.dkr.ecr.us-west-2.amazonaws.com/vp/staging/buildpacks/google/runner:v1 - name: frontend repository: vp-frontend pipeline: buildpack-frontend-build-pipeline applicationURL: https://staging.site.com argocd: syncWave: 220 labels: team: opsteam any-label-name: label-value tekton: workspacePVC: 15Gi buildpacksPVC: 25Gi eventlistener: template: buildpack-frontend-build-pipeline-trigger-template triggerBinding: - name: docker_registry_repository value: xxx.dkr.ecr.us-west-2.amazonaws.com/vp/staging/frontend - name: buildpack_builder_image value: xxx.dkr.ecr.us-west-2.amazonaws.com/vp/staging/buildpacks/paketo/builder:full - name: buildpack_runner_image value: xxx.dkr.ecr.us-west-2.amazonaws.com/vp/staging/buildpacks/paketo/runner:full - name: source_subpath value: dist/web # make sure PVCs are bound after the chart is synced # by temporarily mount them into short-live job. runPostInstallMountPvcJob: false repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.16" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true Above helm chart creates a new ArgoCD project for each project in values, for each component in project's components there is created a separate ArgoCD application and required for Tekton ci/cd resources (triggerbindings, roles, configmaps, jobs, serviceaccounts, pvcs and etc). For each Argocd project, notifications to multiple slack channels with different types of triggers are added. The example above define for each subscription, the slack channels (project-xx, project-xx-ci project-xx-alarms) that should be added by default. This can be modified to add/remove a channel in case of a custom config needed. There are two ways of activating notifications, using slack-token integration and using project-webhooks integration. The slack-token allows sending to any slack channel where the app is installed, that's why we should only use it in rocks/cloud cluster and not in clients clusters. The project-webhook integrations can only send to the channel where it's created in Slack app 'client deployments' (https://api.slack.com/apps/A01LM626QTZ/incoming-webhooks?) and it should be used in staging/prod client clusters. The on-sync-status-unknown subscription is only available for Wordpress applications (it creates redundant notifications for non Wordpress apps) # fill below parameters for each project block - apps[PROJECT].environment - possbility to define custom project's environment, needed for cases when need to deploy dev and prod envs to the same cluster. For example xxx dev and prod both deployed in rocks EKS (not required) - apps[PROJECT].enabled - boolean value to define whether the project enabled or not (required) - apps[PROJECT].argocd.labels - labels which are added to ArgoCD project (required) - apps[PROJECT].argocd.namespace - allowed for ArgoCD project namespace (required) - apps[PROJECT].argocd.notifications.annotations[] - list of slack channels subscriptions, each with a different trigger - apps[PROJECT].argocd.syncWave - ArgoCD project sync wave, i.e. sequence in which project should be synced (not required, default: "200") - apps[PROJECT].argocd.sourceRepos[] - source repositories added to ArgoCD project (not required, default: [<apps[PROJECT].kubernetesRepository.url>]) - apps[PROJECT].argocd.extraDestinationNamespaces[] - adds extra destination namespaces for ArgoCD project to be able to create custom apps within project's kubernetes repo (not required, default: null) - apps[PROJECT].mailList - project's team email address (required) - apps[PROJECT].devopsMailList - project's devops team email address (required) - apps[PROJECT].jiraURL - project's JIRA url (required) - apps[PROJECT].tektonURL - link to Tekton pipelineruns used in Tekton ConfigMap as TEKTON_URL during Slack notification send (required) - apps[PROJECT].slack - project's Slack channel name (required) - apps[PROJECT].kubernetesRepository.name - project's kubernetes repository name used in ArgoCD application and Tekton TriggerBinding (may be absent and replaced with apps[PROJECT].components[NAME].argocd and apps[PROJECT].argocd.sourceRepos[] blocks in case if project has no kubernetes repo) - apps[PROJECT].kubernetesRepository.branch - project's kubernetes repository branch used in ArgoCD application and Tekton TriggerBinding (may be absent and replaced with apps[PROJECT].components[NAME].argocd and apps[PROJECT].argocd.sourceRepos[] blocks in case if project has no kubernetes repo) - apps[PROJECT].kubernetesRepository.url - project's kubernetes repository url used in ArgoCD application and Tekton TriggerBinding (may be absent and replaced with apps[PROJECT].components[NAME].argocd and apps[PROJECT].argocd.sourceRepos[] blocks in case if project has no kubernetes repo) Basically we have 2 different types of ci/cd - basic (buildpacks, kaniko) and wordpress ones. So depending on project's component type you will need to fill different parameters. # fill below parameters for each component block - apps[PROJECT].components[NAME].repository - the name of the repository containing the code (may be absent in case of wordpress application without deployment, i.e. bolrdswp, taco, saritasa-wordpress-demo) - apps[PROJECT].components[NAME].pipeline - the name of the pipeline building the code from t...
saritasa-tekton-pipelines-2.2.14-test.4
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-test.3
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-test.2
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-test.1
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-dev.22
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-dev.21
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-dev.20
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-dev.19
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.
saritasa-tekton-pipelines-2.2.14-dev.18
A Helm chart for Tekton Pipelines Implements: - common tekton tasks - common tekton pipelines - common tekton trigger templates - common tekton trigger bindings Implemented pipelines include: - buildpack based pipelines based on generator template (php, python, frontend, nodejs, ruby, go) - kaniko pipeline - wordpress pipeline ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then if you want to support only frontend and django pipelines based on buildpack without any script modifications: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-pipelines namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "60" spec: destination: server: https://kubernetes.default.svc namespace: ci project: default source: chart: saritasa-tekton-pipelines helm: values: | buildpacks: enabled: true generate: buildpackFrontendBuildPipeline: enabled: true buildpackDjangoBuildPipeline: enabled: true repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true If you want to modify the behavior of the build step you can easily do that by redefining steps you want to run prior to running the build step of the associated buildpack pipeline. You can create multiple versions of pipelines as a result. Just make sure to give them a different name an example: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify build step from buildpack's build Task added by default, you just need to add a new overrideBuildStep key with new step content in values.yaml for required pipeline and helm chart will provision a custom build step: yaml buildpacks: enabled: true generate: buildpackFrontendBuildPipelineNew: name: buildpack-frontend-build-pipeline-new enabled: false buildTaskName: buildpack-frontend-new overrideBuildStep: name: build image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash az login --identity --username <managed-indentity> az acr login --name <container-registry> /cnb/lifecycle/creator \ -app=$(params.source_subpath) \ -project-metadata=project.toml \ -cache-dir=/cache \ -layers=/layers \ -platform=$(workspaces.source.path)/$(params.platform_dir) \ -report=/layers/report.toml \ -cache-image=$(params.cache_image) \ -uid=$(params.user_id) \ -gid=$(params.group_id) \ -process-type=$(params.process_type) \ -skip-restore=$(params.skip_restore) \ -previous-image=$(params.docker_registry_repository) \ -run-image=$(params.run_image) \ $(params.image) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(workspaces.source.path) script: | #!/bin/bash echo "hello world" If you want to modify Kaniko build arguments, you can pass kaniko_extra_args parameter to kaniko-pipeline. For example, if you want to pass BASE_IMAGE build argument value to be used in Dockerfile you can add following line to specific project trigger-binding: yaml - name: kaniko_extra_args value: --build-arg=BASE_IMAGE=965067289393.dkr.ecr.us-west-2.amazonaws.com/saritasa/legacy/php:php71-smart-screen-base Chart has possibility to perform Sentry releases if it is needed, you can configure it by updating below settings in values.yaml: yaml sentry: enabled: true authTokenSecret: "sentry-auth-token" # auth token to connect to Sentry API (change it if you have custom value) authTokenSecretKey: "auth-token" # key for auth token in `authTokenSecret` secret (change it if you have custom value) org: "saritasa" # name of your Sentry organization (change it if you have custom value) url: https://sentry.saritasa.rocks/ # Sentry url (change it if you have custom value) After configuring these values, you will have an extra sentry-release step after argocd-deploy one for buildpacks and kaniko builds.