Hi everyone, We’ve noticed an increasing number of PRs submitted to the Google Provider where contributors—often using AI tooling—don't have access to a GCP project to test their changes.
While we love community contributions, many of these PRs touch critical logic like authentication, base hooks, or core operator behavior with only mocked unit tests. Maintainers are regularly asked to pull these branches and run manual or system tests to see if they actually work against live APIs. Simply put, this doesn't scale. Pulling branches to run ad-hoc system tests takes significant time, and foundational changes often require running multiple full suites. Merging without verification isn't an option either, as catching regressions during release candidate testing blocks releases and creates painful reverts. Proposed Rule We want to agree on a clear baseline for PRs touching functional or auth logic in the Google Provider: 1. *Proof of testing required:* Authors must test against a real GCP project and include proof (logs, CLI output, or run results) in the PR description. 2. *Untested PRs will be put on hold:* Changes affecting runtime behavior without evidence of testing shouldn't be reviewed or merged until validated. 3. *Keep system tests up to date:* New operators or behavior changes should include or update automated system tests, or at minimum show manual end-to-end run results. What we're doing on our end We understand that not everyone has an active GCP environment. On the Google/maintainer side, we’re looking into ways to make it easier to trigger specific existing system tests directly on PR branches via CI for trusted contributors. Until that workflow is ready, the responsibility of proving a change works has to sit with the author. What do you all think? We'd love to hear feedback before updating the provider contribution docs. Best regards, Ulada
