Releases: saritasa-nest/saritasa-devops-helm-charts
saritasa-tekton-pipelines-2.0.0-dev.47
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.46
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.45
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.44
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.43
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.42
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.41
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.
terraform-pod-0.0.38-dev.1
A Helm chart for running infra-dev-aws solutions ## Install the chart Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ ## Use ### Simple case (infra-dev-aws) sh helm upgrade --install CLIENT saritasa/terraform-pod \ --namespace terraform \ --set terraform.client=CLIENT \ --set image.tag=1.12.1 \ --set github.repository=saritasa-nest/CLIENT-infra-dev-aws \ --set github.branch=feature/branch \ --set github.username=YOUR-GITHUB-USERNAME \ --set github.email=YOUR-GITHUB-EMAIL \ --set gitCryptKey=$(base64 -w 0 git-crypt-key) \ --wait ### Passing aws-vault short-term credentials (infra-aws) For infra-aws repos you may want to pass short-term TTL AWS credentials from the aws-vault sh ( unset AWS_VAULT && creds=$(aws-vault exec saritasa/v2/administrators --json) && \ helm upgrade --install CLIENT saritasa/terraform-pod \ --namespace terraform \ --set terraform.client=CLIENT \ --set image.tag=1.12.1 \ --set github.repository=saritasa-nest/CLIENT-infra-aws \ --set github.branch=feature/branch \ --set github.username=YOUR-GITHUB-USERNAME \ --set github.email=YOUR-GITHUB-EMAIL \ --set gitCryptKey=$(base64 -w 0 path/to/git-crypt-key) \ --set terraform.token=xxx \ --set aws.accessKeyId=$(echo $creds | jq -r ".AccessKeyId") \ --set aws.secretAccessKey=$(echo $creds | jq -r ".SecretAccessKey") \ --set aws.sessionToken="$(echo $creds | jq -r ".SessionToken")" \ --set infracost.enabled=true \ --set terraform.initCommand="make _staging init" \ --wait && \ unset creds ) Run command as shown in `()`` so that creds are not exported in your local shell. ## Terminate sh helm delete CLIENT ```` ## Debug If you want to debug the helm chart (after the improvements) you can perform the following sh ( unset AWS_VAULT && creds=$(aws-vault exec saritasa/v2/administrators --json) && \ helm template --release-name debug-tfpod \ --namespace terraform \ --set terraform.client=saritasa \ --set image.tag=1.12.1 \ --set github.repository=saritasa-nest/some-repo-infra-aws \ --set github.branch=feature/branch-name \ --set github.username=your-username \ --set github.email=your-email \ --set gitCryptKey=$(base64 -w 0 git-crypt-key) \ --set aws.accessKeyId="$(echo
saritasa-tekton-pipelines-2.0.0-dev.40
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.0.0-dev.39
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: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" preDeployTaskSteps: - name: pre-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.path) script: | #!/bin/bash echo "hello world" extraPostDeployTaskSteps: - name: post-deploy-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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: $(resources.inputs.app.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=$(resources.outputs.image.url) \ -run-image=$(params.run_image) \ $(resources.outputs.image.url) buildTaskSteps: - name: build-hello-world image: node:22 imagePullPolicy: IfNotPresent workingDir: $(resources.inputs.app.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.