Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
253 lines (233 sloc) 8.19 KB
# 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
# 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:
# 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
hosts: []
paths:
- /
serviceAccount:
create: true
name:
# 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
#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:
# 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
serviceAccount:
create: true
name:
ingress:
enabled: false
# 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:
# 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
You can’t perform that action at this time.