Installing on Buildkite
Configure a Pipeline
Create a new Pipeline for your Workflows build or choose an existing one and configure it to your preference. If you use GitHub, follow these steps to integrate your repo with Buildkite.
Click on Edit Steps
and paste the following:
steps:
- key: aspect-workflows-setup
label: ':aspect: Setup Aspect Workflows'
commands:
- 'rosetta steps | buildkite-agent pipeline upload'
agents:
queue: <QUEUE>
Replace <QUEUE>
with the name of the runner group's queue
in your terraform module declaration. We recommend using aspect-default
which is the
default queue Aspect Workflows queue name. If using a non-default queue name, you'll also need to specify the queue name in your .aspect/workflows/config.yaml
file with queue: <QUEUE>
.
You can use the Buildkite provider for Terraform to set up your pipeline programmatically.
Populate secrets
The Workflows terraform module creates two secrets to populate per runner group.
- Buildkite agent token. The agent token allows our runners to connect to Buildkite. Under your organization, click on the
Agents Tab
then clickReveal Agent Token
. Copy and paste this token into a secret named likeaw_bk_agent_token__<RunnerGroup>_XXXXXXXXXXXXXXXX
.
Alternatively, you can supply the value using Terraform.
We expose the AWS Secrets Manager Secret Id via an output from the Workflows terraform module.
This ID is named bk_agent_token_secret_ids["runner group name"]
where the _runner group name*
matches the bk_runner_groups
input parameter.
For example, if your main.tf
contains
bk_runner_groups = {
default = {
...
}
}
Then you configure this secret with:
resource "aws_secretsmanager_secret_version" "this" {
secret_id = module.aspect-workflows.bk_agent_token_secret_ids["default"]
secret_string = "my-value"
}
The secret_string value should be supplied using whatever mechanism you already use for managing secrets.
- Buildkite API access token. The API token allows us to monitor the agents that we have created for anomalies. Under
Personal Settings
go to theAPI Access Tokens
tab and click theNew API Access Token
button. Give it a name such as "Aspect Workflows API Token" and select your organization from the dropdown. UnderREST API Scopes
we need theRead Agents
permission. Once created, copy and paste this token into a secret named likeaw_bk_api_token__<RunnerGroup>_XXXXXXXXXXXXXXXX
.
Alternatively, you can supply the value using Terraform.
We expose the AWS Secrets Manager Secret Id via an output from the Workflows terraform module.
This ID is named bk_api_token_secret_ids["runner group name"]
where the _runner group name*
matches the bk_runner_groups
input parameter.
For example, if your main.tf
contains
bk_runner_groups = {
default = {
...
}
}
Then you configure this secret with:
resource "aws_secretsmanager_secret_version" "this" {
secret_id = module.aspect-workflows.bk_api_token_secret_ids["default"]
secret_string = "my-value"
}
The secret_string value should be supplied using whatever mechanism you already use for managing secrets.
- Git SSH key. If you use a private repository, set up an SSH key that Workflows runners can use to check out your repository. Under your pipeline's GitHub settings, select the
SSH
radio button. Then, upload the private key to a secret with a name likeaw_bk_git_ssh_key__<RunnerGroup>-XXXXXXXX
. If you use GitHub, we recommend using a Deploy Key with readonly access.
Alternatively, you can supply the value using Terraform.
We expose the AWS Secrets Manager Secret Id via an output from the Workflows terraform module.
This ID is named bk_git_ssh_key_secret_ids["runner group name"]
where the _runner group name*
matches the bk_runner_groups
input parameter.
For example, if your main.tf
contains
bk_runner_groups = {
default = {
...
}
}
Then you configure this secret with:
resource "aws_secretsmanager_secret_version" "this" {
secret_id = module.aspect-workflows.bk_git_ssh_key_secret_ids["default"]
secret_string = "my-value"
}
The secret_string value should be supplied using whatever mechanism you already use for managing secrets.
The Workflows module exposes the names of the secrets it creates as an outputs. If you use a tool like Vault, you can wire in secret values automatically via Terraform.
Configure workflows
Add a Workflows configuration file to your repository.
(Optional) Custom Buildkite agent hooks
The Buildkite agent allows you to declare custom hooks which it runs at various points throughout the lifecycle of a build.
- AWS
- GCP
To supply your own hook, add the hook to the S3 bucket named aw_buildkite_agent-hooks_XXXXXXXXX
under the global/
folder. Runners will find the hooks and install them for the buildkite agent to use.
To supply your own hook, add the hook to the GCS bucket named aw-buildkite-agent-hooks-XXXXXXXXX
under the global/
folder. Runners will find the hooks and install them for the buildkite agent to use.
Hooks under the global/
folder are shared across runner groups. In the future, we will support per-runner-group hooks.
Not recommended: You can alternatively add hooks to your runner image under the directory /opt/buildkite-agent-hooks
.
This approach requires rebuilding your runner image each time you change the hooks.
Hooks found in the bucket will override hooks found in this directory.
At the moment, we do not support pre-checkout
and post-checkout
hooks. These hooks will be ignored if added.
You may wish to alternatively try Aspect Workflow's native hooks solution, which allows you to execute code before and after tasks.