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.29k stars 1.72k forks source link

TeamCity: Add validating GHAs that check Kotlin files listing services in GA and Beta providers are up to date #17168

Closed SarahFrench closed 6 months ago

SarahFrench commented 7 months ago

Background

See comment thread here: https://github.com/GoogleCloudPlatform/magic-modules/pull/9837#discussion_r1474242334

Following the TeamCity config refactor, these files will need to be manually maintained and there's a chance of drift happening:

To avoid this, we should have GHAs in TPG/TPGB repos to confirm the services in the relevant file match the packages present in the provider code.

What kind of contribution is this issue about?

Related PR(s), if any:

Details

SarahFrench commented 7 months ago

@BBBmau this might be a fun ticket to work on - interested?

SarahFrench commented 7 months ago

Notes from triage:

SarahFrench commented 7 months ago

Background

When users add a new service to the provider we need to make sure TeamCity creates a new build configuration for that service, to run acceptance tests in:

Screenshot 2024-02-06 at 19 37 35 [screenshot of the start of a list of build configurations for each service in the GA provider]

With the new TeamCity code that's about to go live there are two input lists that let the TeamCity config know what service packages are present in the GA and Beta versions of the provider. You can see an example of the files below on this branch.

The lists in those files need to be maintained manually, due to long-winded reasons (happy to discuss in 1:1). This opens up the risk of drift; users may add support for services and not update the lists, resulting in tests not running in TeamCity.

Solution ideas

Ideally the solution to this would be automation present in the magic-modules repo that identifies the problem either in the PR adding the new service, or checks that happen on main branch immediately after the PR is merged.

The tool would need to compare the contents of the file above to the packages present in the provider(s).

We can take inspiration from existing GHAs to learn how the GHA can have access to the built providers:

**jobs:

  terraform-provider-google:
    uses: ./.github/workflows/build-downstream.yml
    with:
      repo: 'terraform-provider-google'
  terraform-provider-google-beta:
    uses: ./.github/workflows/build-downstream.yml
    with:
      repo: 'terraform-provider-google-beta'**

Once you have the provider codebase for a given PR (or main of MM) accessible you can determine which service packages are present either by iterating through the folders in the google(-beta)/services/ folder, or use a command like this to get all service packages present in the provider:

# Go to root of provider
$ cd terraform-provider-google

# Use go list 
go list ./google/services/... | sed 's/github.com\/hashicorp\/terraform-provider-google\/google\/services\///'

# Returns a list starting with:
# accessapproval
# accesscontextmanager
# activedirectory
# alloydb
# apigee
# apikeys
# appengine
# ...

The tool would need to generate both providers and compare the list of service packages from the process above with the contents of .teamcity/components/inputs/services_ga.kt (or services_beta.kt) and highlight any discrepancies. To start, it's fine to just identify when services are present in the provider but absent from the Kotlin file for the given provider, but identifying discrepancies both ways would be useful!

How to test

You could start making a script that can run using a local copy of terraform-provider-google(-beta) on your laptop to identify discrepancies.

Then you could adapt it into a GHA. You can make a personal fork of the magic-modules repo and experiment there freely, just make sure to not accidentally open PRs against the original repo!

After making a GHA that can be triggered manually to detect the drift, you could then work to make it triggered by PRs, or by merges to main branch.

SarahFrench commented 7 months ago

@BBBmau above is some details about this ticket! DM me for additional context or details 📫

github-actions[bot] commented 5 months ago

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.