Hi Ulada, You have really, really missed the mark in the tone you used on **your very first email** to the dev list.
"We want a clear baseline” - who is “we"? Who are you even? I find this very rude phrasing, and almost totally blind to how the Airflow community works. Phrase it as “I would like to propose” and it reads much better. Also: You work for trillion dollar company. If this is important to Google: show us the money. Give us the credits to let every pr to the Google PR run against real GCP things. Thanks, Ash > On 5 Oct 2026, at 14:46, Ulada Zakharava (xWF) <[email protected]> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
