Skip to content
Permalink
main
Switch branches/tags
Go to file
 
 
Cannot retrieve contributors at this time
## This is the main configuration file for the Brigade chart.
## To override values here, specify them in your own YAML file, and override
## during install or upgrade:
##
## $ helm install -n brigade -f myValues.yaml brigade/brigade
##
## By default, the chart will install with RBAC. To install without
## RBAC, set `rbac.enabled` to `false`.
##
## To enable the GitHub gateway, set `brigade-github-app.enabled` to `true`.
## See brigadecore/brigade-gitub-app for steps to setup a Github App and add its configuration
## to the sub-chart section below.
##
## Advanced Configuration
##
## Developers may wish to override the location of Docker images. For each
## deployment, `registry` controls the image registry, and `name` controls
## the image name. If unspecified, the Chart.yaml's appVersion field will be
## used to pull the tag. If you override the `tag` value, that version will
## be used instead.
##
## Note that when `rbac.enabled` is turned on, as is the default, the chart will
## install a set of RBAC objects that are designed to give a moderate set of
## permissions to the Brigade core components. However, even if RBACs are not
## enabled, this chart will create service accounts for each entity that we
## install. Security experts may prefer to apply their own RBACs instead of the
## ones supplied by the chart. Provided that the service accounts remain the
## same, this chart should provide compatibility with custom rules.
#########################
# Sub-chart configuration
#########################
## Kashti, the Brigade Dashboard, is enabled by default.
##
## These resources are included by way of a sub-chart dependency (see requirements.yaml)
##
## Further configurability of Kashti-specific values would also go here, e.g.
## kashti:
## image:
## repository: myrepository
## ...
##
## For full configuration, see the kashti chart in this repository and its values.yaml.
kashti:
enabled: true
## Brigade Github App, the GitHub Gateway for Brigade, is disabled by default.
##
## These resources are included by way of a sub-chart dependency (see requirements.yaml)
##
## Further configurability of Brigade Github App-specific values would also go here, e.g.
## brigade-github-app:
## github:
## appID: myGithubAppID
## ...
##
## For full configuration, see the brigade-github-app chart in this repository
brigade-github-app:
enabled: false
github:
## Set a defaultSharedSecret if you want to use this one instance of the
## Github gateway with multiple Brigade projects. Leave the shared secret
## field blank in project-level configuration and this default will be used.
# defaultSharedSecret:
## gw is the deprecated Oauth-based GitHub Gateway that shipped with Brigade <= v0.20
##
## Its alias has been preserved as `gw` to support legacy Brigade installations,
## although the chart name is `brigade-github-oauth`.
##
## We recommend users switch to the fully-supported Brigade GitHub App (configured above) instead.
##
## For full configuration, see the brigade-github-oauth chart in this repository
gw:
enabled: false
#############################
# Brigade chart configuration
#############################
## IMPORTANT: The RBAC system is complex, and if you are using RBACs in your
## cluster, you may need to evaluate existing rules and accounts in addition
## to the rules created here.
rbac:
enabled: true
## controller is the main event processor in Brigade.
controller:
enabled: true
registry: brigadecore
name: brigade-controller
## tag should only be specified if you want to override Chart.appVersion
## The default tag is the value of .Chart.AppVersion
# tag:
# pullPolicy: IfNotPresent
# workerResources:
# limits:
# cpu:
# memory:
# requests:
# cpu:
# memory:
serviceAccount:
create: true
name:
imagePullSecrets: []
## Add custom annotations to the controller pod
# podAnnotations:
# name: value
## api is the API server. It is technically not needed for the operation of the
## Brigade controller, but it is used by tools to learn about the state of the
## cluster.
##
## If you disable it, Brigade will still process events, but extra tooling (like
## brig) may not be able to learn about it.
api:
enabled: true
registry: brigadecore
name: brigade-api
# tag:
service:
name: brigade-api
type: ClusterIP
externalPort: 7745
internalPort: 7745
## Configure liveness probes except `httpGet`
# livenessProbe:
# initialDelaySeconds: 20
## Configure readiness probes except `httpGet`
# readinessProbe:
# initialDelaySeconds: 20
ingress:
enabled: false
# From Kubernetes 1.18+ this field is supported in case your ingress controller supports it. When set, you do not need to add the ingress class as annotation.
ingressClassName:
hosts: []
paths:
- /
serviceAccount:
create: true
name:
imagePullSecrets: []
## Add custom annotations to the api pod
# podAnnotations:
# name: value
## worker is the JavaScript worker. These are created on demand by the controller.
worker:
registry: brigadecore
name: brigade-worker
# command:
serviceAccount:
create: true
name: brigade-worker
## This SA is the default used by all workers and jobs unless otherwise
## specified. Referencing image pull secrets (which must be created
## separately) from this SA is a convenient way to ensure those image pull
## secrets are available to ALL workers and jobs (or at least those using
## this SA) WITHOUT needing to explicitly reference those image pull secrets
## on every worker or job definition. This is useful, for instance, for
## circumventing some registries' rate limits by using a paid account with
## unlimited image pulls.
imagePullSecrets: []
# tag:
# pullPolicy: IfNotPresent
# defaultBuildStorageClass:
# defaultCacheStorageClass:
## These values are for the Container Registry (CR) gateway.
## Enabling this will start a service that handles webhooks from container
## registries like DockerHub and ACR. Note that these registries do not have
## strong auth built in, so enabling this gateway could result in repeated
## bogus requests from an unauthenticated source. This could pose a security
## risk for poorly written scripts, and could be an opening for DOS-style
## attacks on your cluster.
cr:
enabled: false
registry: brigadecore
name: brigade-cr-gateway
# tag: latest
service:
name: brigade-cr-service
type: ClusterIP # Change to LoadBalancer if you want this externally available.
externalPort: 80
internalPort: 8000
## Configure liveness probes except `httpGet`
# livenessProbe:
# initialDelaySeconds: 20
## Configure readiness probes except `httpGet`
# readinessProbe:
# initialDelaySeconds: 20
serviceAccount:
create: true
name:
imagePullSecrets: []
## Add custom annotations to the cr gateway pod
# podAnnotations:
# name: value
## These values are for the Generic Gateway.
## Enabling this will start a service that handles webhooks from external clients.
## To call this endpoint you need a special secret value that is configured once per project.
genericGateway:
enabled: false
registry: brigadecore
name: brigade-generic-gateway
# tag: latest
service:
name: brigade-generic-service
type: ClusterIP # Change to LoadBalancer if you want this externally available.
externalPort: 8081
internalPort: 8000
annotations: {}
serviceAccount:
create: true
name:
imagePullSecrets: []
ingress:
enabled: false
# From Kubernetes 1.18+ this field is supported in case your ingress controller supports it. When set, you do not need to add the ingress class as annotation.
ingressClassName:
## Add custom annotations to the generic gateway pod
# podAnnotations:
# name: value
## use the correct annotation for your certificate provider
## the following config works according to the Brigade docs
## which show how to use Nginx Ingress Controller and cert-manager
##
## Note: if you delete the ingress resource and re-create it on the same subdomain, make sure
## to delete the secret before trying again.
# annotations:
# kubernetes.io/ingress.class: "nginx"
# certmanager.k8s.io/cluster-issuer: "letsencrypt-prod"
# certmanager.k8s.io/acme-challenge-type: http01
# hosts:
# - brigade-events.subdomain.domain.com
# paths:
# - /
# tls:
# - secretName: brigade-events
# hosts:
# - brigade-events.subdomain.domain.com
## The vacuum periodically cleans up old builds.
## Brigade does not delete builds on completion. Instead, it leaves builds around
## for a period of time, providing you with an opportunity to inspect builds for
## data.
## The vacuum will sweep the system at intervals and clear out old builds.
##
## To globally turn of the vacuum, set enabled=false
vacuum:
enabled: true
## Set a schedule for how frequently this check is run.
## Note that a run of the vacuum typically takes at least a minute. Finer-level
## granularity than that may result in multiple vacuums running at once.
## Format follows accepted Cron formats: https://en.wikipedia.org/wiki/Cron
schedule: "@hourly"
registry: "brigadecore"
name: "brigade-vacuum"
# tag: latest
## Age tells the vacuum how old a thing may be before it is considered ready to
## be vacuumed. The format is an integer followed by the suffix h (hours), m (minutes)
## or s (seconds).
## The default is 30 days (720 hours)
age: "720h"
## maxBuilds tells the vacuum what the absolute maximum number of builds may be stored
## at a time. Where possible, we recommend using age rather than builds.
## -1 means no limit is imposed.
##
## If both age and maxBuilds are provided, age is applied first, then maxBuilds.
maxBuilds: -1
serviceAccount:
create: true
name:
imagePullSecrets: []
## The following options have to do with cleaning up after the vacuum jobs
## themselves so completed jobs don't endlessly accumulate in the cluster.
##
## The maximum number of successful vacuum jobs to retain in the cluster.
## Set this to 0 if you feel like no news is good news.
successfulJobsHistoryLimit: 10
## The maximum number of failed vacuum jobs to retain in the cluster.
failedJobsHistoryLimit: 10
## DEVELOPMENT ONLY: Use this for off-ACS development
## Before enabling this, log into the acr registry with Docker and then
## run `scripts/generate-acr-secret.sh`
# privateRegistry: brigade-registry