saritasa-tekton-apps-1.1.2

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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component ArgoCD appli...

saritasa-tekton-apps-1.1.1

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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component ArgoCD appli...

saritasa-tekton-apps-1.1.0-dev.5

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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component ArgoCD appli...

saritasa-tekton-apps-1.1.0

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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component ArgoCD appli...

saritasa-tekton-1.1.0-dev.3

A Helm chart for Tekton. Implements: - tekton engine - tekton dashboard - tekton triggers - tekton dashboard ingress - webhook ingress ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then create the manifest and apply: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-engine namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "40" spec: destination: server: https://kubernetes.default.svc namespace: tekton-pipelines project: default source: chart: saritasa-tekton helm: values: | domainZone: staging.site.com # install engine engine: enabled: true config: defaultServiceAccount: "build-bot-sa" defaultTimeoutMinutes: "60" defaultPodTemplate: | nodeSelector: ci: "true" # install triggers triggers: enabled: true # install dashboard with a public ingress dashboard: enabled: true ingress: enabled: true annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-body-size: 100m cert-manager.io/cluster-issuer: "letsencrypt-prod" nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: tekton-basic-auth nginx.ingress.kubernetes.io/auth-realm: "Authentication Required" argocd.argoproj.io/sync-wave: "1" hosts: - host: tekton.staging.site.com paths: - path: / pathType: Prefix backend: service: name: tekton-dashboard port: number: 9097 tls: - secretName: tekton.staging.site.com-crt hosts: - tekton.staging.site.com # install github webhook ingress that invokes tekton's eventlistener webhook: enabled: true namespace: "ci" ingress: enabled: true annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-body-size: 100m cert-manager.io/cluster-issuer: "letsencrypt-prod" argocd.argoproj.io/sync-wave: "10" hosts: - host: webhook.staging.site.com paths: - path: / pathType: Prefix backend: service: name: el-build-pipeline-event-listener port: number: 8080 tls: - secretName: webhook.staging.site.com-crt hosts: - webhook.staging.site.com eventlistener: create: true labelSelector: builder: tekton namespaceSelector: - ci - ci-experiments serviceAccount: create: true name: "build-bot-sa" nodeSelector: tekton_builder: "true" repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true Keep in mind that tekton has config-default configmap, an example you can see here. You can customize it values in this map engine.config: {}. Just add keys in the map and they will be added into the tekton-pipelines/config-defaults configmap. yaml engine: config: defaultServiceAccount: "build-bot-sa" defaultTimeoutMinutes: "60" defaultPodTemplate: | nodeSelector: ci: "true" If you want to pull images from a private registry (or if you want to skip 200 pulls on dockerhub) imagePullSecrets: - name: "your-docker-secret-name" You can generate that secret by doing the following kubectl create secret -n argo-cd generic docker-saritasa-infra-v2-ro \ --from-file=.dockerconfigjson=~/.docker/config.json \ --type=kubernetes.io/dockerconfigjson Make dure this ~/.docker/config.json is cleaned from non-infra-v2 registries first.

saritasa-tekton-1.1.0-dev.2

A Helm chart for Tekton. Implements: - tekton engine - tekton dashboard - tekton triggers - tekton dashboard ingress - webhook ingress ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then create the manifest and apply: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-engine namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "40" spec: destination: server: https://kubernetes.default.svc namespace: tekton-pipelines project: default source: chart: saritasa-tekton helm: values: | domainZone: staging.site.com # install engine engine: enabled: true config: defaultServiceAccount: "build-bot-sa" defaultTimeoutMinutes: "60" defaultPodTemplate: | nodeSelector: ci: "true" # install triggers triggers: enabled: true # install dashboard with a public ingress dashboard: enabled: true ingress: enabled: true annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-body-size: 100m cert-manager.io/cluster-issuer: "letsencrypt-prod" nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: tekton-basic-auth nginx.ingress.kubernetes.io/auth-realm: "Authentication Required" argocd.argoproj.io/sync-wave: "1" hosts: - host: tekton.staging.site.com paths: - path: / pathType: Prefix backend: service: name: tekton-dashboard port: number: 9097 tls: - secretName: tekton.staging.site.com-crt hosts: - tekton.staging.site.com # install github webhook ingress that invokes tekton's eventlistener webhook: enabled: true namespace: "ci" ingress: enabled: true annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-body-size: 100m cert-manager.io/cluster-issuer: "letsencrypt-prod" argocd.argoproj.io/sync-wave: "10" hosts: - host: webhook.staging.site.com paths: - path: / pathType: Prefix backend: service: name: el-build-pipeline-event-listener port: number: 8080 tls: - secretName: webhook.staging.site.com-crt hosts: - webhook.staging.site.com eventlistener: create: true labelSelector: builder: tekton namespaceSelector: - ci - ci-experiments serviceAccount: create: true name: "build-bot-sa" nodeSelector: tekton_builder: "true" repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true Keep in mind that tekton has config-default configmap, an example you can see here. You can customize it values in this map engine.config: {}. Just add keys in the map and they will be added into the tekton-pipelines/config-defaults configmap. yaml engine: config: defaultServiceAccount: "build-bot-sa" defaultTimeoutMinutes: "60" defaultPodTemplate: | nodeSelector: ci: "true" If you want to pull images from a private registry (or if you want to skip 200 pulls on dockerhub) imagePullSecrets: - name: "your-docker-secret-name" You can generate that secret by doing the following kubectl create secret -n argo-cd generic docker-saritasa-infra-v2-ro \ --from-file=.dockerconfigjson=~/.docker/config.json \ --type=kubernetes.io/dockerconfigjson Make dure this ~/.docker/config.json is cleaned from non-infra-v2 registries first.

saritasa-tekton-1.1.0

A Helm chart for Tekton. Implements: - tekton engine - tekton dashboard - tekton triggers - tekton dashboard ingress - webhook ingress ## example usage with argocd Install the chart: helm repo add saritasa https://saritasa-nest.github.io/saritasa-devops-helm-charts/ then create the manifest and apply: yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: tekton-engine namespace: argo-cd finalizers: - resources-finalizer.argocd.argoproj.io annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/sync-wave: "40" spec: destination: server: https://kubernetes.default.svc namespace: tekton-pipelines project: default source: chart: saritasa-tekton helm: values: | domainZone: staging.site.com # install engine engine: enabled: true config: defaultServiceAccount: "build-bot-sa" defaultTimeoutMinutes: "60" defaultPodTemplate: | nodeSelector: ci: "true" # install triggers triggers: enabled: true # install dashboard with a public ingress dashboard: enabled: true ingress: enabled: true annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-body-size: 100m cert-manager.io/cluster-issuer: "letsencrypt-prod" nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: tekton-basic-auth nginx.ingress.kubernetes.io/auth-realm: "Authentication Required" argocd.argoproj.io/sync-wave: "1" hosts: - host: tekton.staging.site.com paths: - path: / pathType: Prefix backend: service: name: tekton-dashboard port: number: 9097 tls: - secretName: tekton.staging.site.com-crt hosts: - tekton.staging.site.com # install github webhook ingress that invokes tekton's eventlistener webhook: enabled: true namespace: "ci" ingress: enabled: true annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-body-size: 100m cert-manager.io/cluster-issuer: "letsencrypt-prod" argocd.argoproj.io/sync-wave: "10" hosts: - host: webhook.staging.site.com paths: - path: / pathType: Prefix backend: service: name: el-build-pipeline-event-listener port: number: 8080 tls: - secretName: webhook.staging.site.com-crt hosts: - webhook.staging.site.com eventlistener: create: true labelSelector: builder: tekton namespaceSelector: - ci - ci-experiments serviceAccount: create: true name: "build-bot-sa" nodeSelector: tekton_builder: "true" repoURL: https://saritasa-nest.github.io/saritasa-devops-helm-charts/ targetRevision: "0.1.4" syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true Keep in mind that tekton has config-default configmap, an example you can see here. You can customize it values in this map engine.config: {}. Just add keys in the map and they will be added into the tekton-pipelines/config-defaults configmap. yaml engine: config: defaultServiceAccount: "build-bot-sa" defaultTimeoutMinutes: "60" defaultPodTemplate: | nodeSelector: ci: "true" If you want to pull images from a private registry (or if you want to skip 200 pulls on dockerhub) imagePullSecrets: - name: "your-docker-secret-name" You can generate that secret by doing the following kubectl create secret -n argo-cd generic docker-saritasa-infra-v2-ro \ --from-file=.dockerconfigjson=~/.docker/config.json \ --type=kubernetes.io/dockerconfigjson Make dure this ~/.docker/config.json is cleaned from non-infra-v2 registries first.

saritasa-tekton-apps-1.1.0-dev.4

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 eventlistener: enableWebhookSecret: true labelSelector: 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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component...

saritasa-tekton-apps-1.1.0-dev.3

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 eventlistener: enableWebhookSecret: true labelSelector: 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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component...

saritasa-tekton-apps-1.1.0-dev.2

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 eventlistener: enableWebhookSecret: true labelSelector: 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 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 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 the repository above - apps[PROJECT].components[NAME].namespace - the name of the namespace for component. Optional parameter - apps[PROJECT].components[NAME].argocd.source.syncWave - custom component...