page_title |
---|
Upgrading to v1.0 |
The Buildkite Terraform provider 1.0 is considered stable and ready for production use. If you have been using the
provider prior to the 1.0 release, this guides you through upgrading.
If you are starting a new terraform project with this provider, you can start at https://registry.terraform.io/providers/buildkite/buildkite/latest/docs.
The provider has been upgraded to protocol v6. It is therefor only compatible with terraform CLI version 1.0 and later.
You are now able to manage cluster resources with the provider. This includes buildkite_cluster
., buildkite_cluster_queue
, and
buildkite_cluster_agent_token
.
You can now create test suites and assign teams access to them with buildkite_test_suite
, and buildkite_test_suite_team
.
API retries and timeouts have been implemented in the majority of resources. This adds reliability to the provider around API latency and outages.
By default, retries are set to 30 seconds. You can override this by operation type on the provider settings:
provider "buildkite" {
organization = "buildkite"
timeouts = {
create = "90s"
delete = "10s"
}
}
Pipeline resources can now be archived instead of deleted when the resource is destroyed. This might be useful for users who wish to keep the history around but disable the pipeline. This is configurable at the provider level:
provider "buildkite" {
organization = "buildkite"
archive_pipeline_on_delete = true
}
The provider_settings
attribute on the pipeline resource has been completely overhauled. It is now a nested attribute
(thanks to protocol v6) and has validation on its inner attributes.
Previously:
resource "buildkite_pipeline" "pipeline" {
name = "deploy"
repository = "https://github.com/company/project.git"
provider_settings {
trigger_mode = "deployment"
}
}
Now, provider_settings
is a nested attribute:
resource "buildkite_pipeline" "pipeline" {
name = "deploy"
repository = "https://github.com/company/project.git"
provider_settings = {
trigger_mode = "deployment"
}
}
All resources now use their GraphQL IDs as the primary ID in the schema.
team
attribute on pipeline resource has been removed. It is replaced by the separate resourcebuildkite_pipeline_team
.
~> If you are coming from a 0.x release of the provider and using buildkite_pipeline.team
attribute on your resources,
you must upgrade to version 0.27.0 with the newer resource using an Administrator scoped API Access Token prior to upgrading to v1.0.
See Migrate pipeline.team usage to buildkite_pipeline_team resource for more info.
State file backups are created automatically by terraform. You should inspect your state storage location and ensure there is a valid backup available in the event of corruption from upgrading the provider.
Refer to https://developer.hashicorp.com/terraform/cli/state/recover for more information.
You should pin your provider installation to the 1.x releases so you can upgrade as new versions are released.
terraform {
required_providers {
buildkite = {
source = "buildkite/buildkite"
version = "~> 1.0"
}
}
}
After pinning the provider version, you can upgrade it by running: terraform init -upgrade
. This will pull in the
latest release under the 1.x version.
The next step is to refresh your state file: terraform refresh
.
The team
attribute on the pipeline
resource was removed in v1.0 in favour of a separate resource:
buildkite_pipeline_team
.
You'll need to upgrade your provider to version 0.27.0
and switch over to the new resource prior to upgrading to v1.0.
Before this change:
resource "buildkite_team" "deploy" {
name = "deploy"
privacy = "VISIBLE"
default_team = true
default_member_role = "MEMBER"
}
# only allow the deploy team to build the deploy pipeline
resource "buildkite_pipeline" "pipeline" {
name = "deploy"
repository = "https://github.com/company/project.git"
team {
slug = "deploy"
access_level = "BUILD_AND_READ"
}
}
After this change:
resource "buildkite_team" "deploy" {
name = "deploy"
privacy = "VISIBLE"
default_team = true
default_member_role = "MEMBER"
}
resource "buildkite_pipeline" "pipeline" {
name = "deploy"
repository = "https://github.com/company/project.git"
}
# only allow the deploy team to build the deploy pipeline
resource "buildkite_pipeline_team" "deploy_pipeline" {
pipeline_id = buildkite_pipeline.pipeline.id
team_id = buildkite_team.deploy.id
access_level = "BUILD_AND_READ"
}
After applying that change to all pipeline
resources with a team
attribute, you can run an apply: terraform apply
.
This will show something like below. You can see in the plan that it will temporarily remove the team from the pipeline, then followup with adding it back through the separate resource. This will result in a very small time window where the team doesn't have access to the pipeline. It should be unnoticeable.
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
~ update in-place
Terraform will perform the following actions:
# buildkite_pipeline.pipeline will be updated in-place
~ resource "buildkite_pipeline" "pipeline" {
id = "<obfuscated>"
name = "v0.27"
tags = []
# (10 unchanged attributes hidden)
- team {
- access_level = "READ_ONLY" -> null
- pipeline_team_id = "<obfuscated>" -> null
- slug = "team" -> null
- team_id = "<obfuscated>" -> null
}
}
# buildkite_pipeline_team.p_team will be created
+ resource "buildkite_pipeline_team" "p_team" {
+ access_level = "READ_ONLY"
+ id = (known after apply)
+ pipeline_id = "<obfuscated>"
+ team_id = "<obfuscated>"
+ uuid = (known after apply)
}
Plan: 1 to add, 1 to change, 0 to destroy.
This is as simple as adding an equal sign (=
) to the provider_settings
attribute and running terraform apply
.
The provider will transparently update the state file to the new schema version. This operation is not automatically reversible. If you run into issues from upgrading, please raise an issue on GitHub.
See Pipeline resource provider_settings
type change for an example.
If you experience issues with the automatic upgrade you can revert your changes and re-instate the backup terraform state file. Follow the instructions from Terraform on disaster recovery: https://developer.hashicorp.com/terraform/cli/state/recover.