MySQL Data Storage
BuildBuddy uses a SQL connection string to specify the database it will connect to. An example string is:- Create a new database on your MySQL server
- Create a new user with full access to that database
- Put the username, password, IP address of your MySQL server, and database name into the BuildBuddy data_source connection string:
config.yaml
If using the BuildBuddy Enterprise Helm charts, MySQL can be configured for you using the
mysql.enabled, mysql.username, and mysql.password values.Default Redis Target
For a BuildBuddy deployment running multiple apps, it is necessary to provide a default redis target for some features to work correctly. Metrics collection, usage tracking, and responsive build logs all depend on this. If no default redis target is configured, we will fall back to using the cache redis target, if available, and then the remote execution target, if available. The default redis target also acts as the primary fallback if the remote execution redis target is left unspecified. The default redis target does NOT act as a fallback for the cache redis target. The configuration below demonstrates a default redis target:config.yaml
GCS Based Cache / Object Storage / Redis
By default, BuildBuddy will cache objects and store uploaded build events on the local disk. If you want to store them in a shared durable location, like a Google Cloud Storage bucket, you can do that by configuring a GCS cache or storage backend. If your BuildBuddy instance is running on a machine with Google Default Credentials, no credentials file will be necessary. If not, you should create a service account with permissions to write to cloud storage, and download the credentials .json file. We also recommend providing a Redis instance for improved remote build execution & small file performance. This can be configured automatically using the BuildBuddy Enterprise Helm charts with theredis.enabled value.
The configuration below configures Redis & GCS storage bucket to act as a storage backend and cache:
config.yaml
config.yaml
Authentication Provider Integration
BuildBuddy supports OpenID Connect (OIDC) as a way of interacting with an Auth Provider like Google, Okta, or similar to authenticate your users when they log in. Configuring this is easy, below is an example of using BuildBuddy with Okta. Configuring your Auth Provider to support OIDC is outside the scope of this doc, but we’ve done it for Google, Okta, and others, and are happy to lend a helping hand if you’re stuck.config.yaml
config.yaml
Certificate Based Authentication
Your users can authenticate to BuildBuddy using an API key or they can use Certificate based authentication over mTLS. To configure mTLS, you must generate a new server certificate authority and key. You can do this using theopenssl command, for example:
config.yaml
Remote Build Execution
To enable Remote Build Execution, you’ll need to add the following to your config.yaml:config.yaml
Putting It All Together
Here’s what a fully-featured config.yaml looks like which includes all of the features listed above.config.yaml