search

hashicorp / terraform-provider-google

Terraform Provider for Google Cloud Platform
https://registry.terraform.io/providers/hashicorp/google/latest/docs
Mozilla Public License 2.0
2.33k stars 1.73k forks source link

Add automation to assert that our release process is overwriting `version.ProviderVersion` correctly, resulting in accurate User-Agent values #19777

Open SarahFrench opened 2 weeks ago

SarahFrench commented 2 weeks ago

What kind of contribution is this issue about?

Other (specify in details)

Details

Our release process uses ldflags to overwrite the variable version.ProviderVersion. In our codebase version.ProviderVersion is "dev" but when we build and release a new provider version the value is replaced with "9.9.9", etc. This value is used to create the User-Agent header in the provider.

ldflags in our release tooling - .goreleaser.yml:

    ldflags:
      - -s -w -X github.com/hashicorp/terraform-provider-google<%= "-" + version unless version == 'ga' -%>/version.ProviderVersion={{.Version}}

Example User-Agent:

User-Agent: google-api-go-client/0.5 Terraform/1.8.0 (+https://www.terraform.io) Terraform-Plugin-SDK/2.33.0 terraform-provider-google/6.6.0

When we run acceptance tests the version.ProviderVersion value isn't overwritten, so the User-Agent will contain terraform-provider-google/dev.

There was a period of time in the past where overwriting that value was not working (fixed here https://github.com/GoogleCloudPlatform/magic-modules/pull/6929) and that means some 4.X.X versions of the providers have user agents that are indistinguishable from acceptance tests.

We should add testing to assert that the release process is overwriting version.ProviderVersion as expected.

Here is some information from here that suggests a method of doing that:

The testing I used when https://github.com/GoogleCloudPlatform/magic-modules/pull/6929 was like this, and can be done by anyone:

  1. Checkout a release branch in the TPG/TPGB repo : git checkout release-6.6.0 a. This is necessary to control which version of the provider we test releasing; that's what is released, and release branches are where our release tags are.
  2. Run this command in the repo: goreleaser build --single-target --debug --rm-dist --skip-validate a. This just builds a binary on your machine, so no worries about impacting anything user-facing. b. A binary is made in a new dist directory in the repo c. The debug output shows how ProviderVersion is overwritten and what the resulting command is, e.g: go build -trimpath -ldflags=-s -w -X github.com/hashicorp/terraform-provider-google/version.ProviderVersion=6.6.0 -o /Users/sarahfrench/go/src/github.com/hashicorp/terraform-provider-google/dist/terraform-provider-google_darwin_arm64/terraform-provider-google_v6.6.0_x5 .
  3. You can then move that binary to ~/go/bin and use development overrides to make Terraform use that binary as the Google provider. If you run a terraform command with that override and TF_LOG=DEBUG you can see the UserAgent value there.

We could make some automated tests to check on this:

In CI, checkout the latest release branch in the TPG/TPGB repo and run the goreleaser command above Run a very simple acceptance test with debug logging enabled, write that debug log output to file Grep the file for the User-Agent value and assert that the UA matches the checked out release branch

References

No response

SarahFrench commented 2 weeks ago

This could be implemented as a GitHub Action on the downstream repos:

This would mean PRs used to prepare CHANGELOGS on release branches would see if a given release was going to be impacted by a problem generating the correct user agent.

Alternatively, this could be implemented in Cloud Build in the magic-modules repo. This is possible because the MM repo controls the .goreleaser.yml file in the downstreams, so it can generate the provider repo in CI and it will have all the necessary files for running the goreleaser command described above.