`pre-commit` check frequently fails on Copybara pushes to `main`, blocking external contributors

[primenko-v]

The pre-commit CI check frequently fails on commits pushed to main by copybara-service. Filtering the Actions tab by is:failure branch:main shows 90+ failures, all from the internal pipeline.

Since pre-commit/action runs --all-files, any external PR that touches .py files inherits these pre-existing failures and cannot pass CI — even when the PR's own changes are correctly formatted.

Example: commit e5af12c2 introduced formatting issues in:

• src/google/adk/flows/llm_flows/base_llm_flow.py
• src/google/adk/flows/llm_flows/basic.py
• src/google/adk/models/gemini_llm_connection.py
• tests/unittests/flows/llm_flows/test_base_llm_flow.py
• tests/unittests/models/test_gemini_llm_connection.py

The check ran and failed, but since the changes were pushed directly, the check is just informational. As a result, contributor branches are now also failing — see here.

Ask: Could the internal pipeline run isort and pyink before syncing to GitHub, to match the public pre-commit checks?

[adk-bot]

GitHub Issue #5963 Analysis: pre-commit check frequently fails on Copybara pushes to main, blocking external contributors

Detailed Analysis

1. Root Cause Analysis ("What is broken?")

The ADK-Python repository utilizes a GitHub Actions workflow defined in pre-commit.yml which executes pre-commit/action@v3.0.1. By default, this action runs:
pre-commit run --all-files
under both push and pull_request triggers to verify compliance with the formatting and style rules defined in .pre-commit-config.yaml.

The breakdown occurs due to a mismatch between Google's internal pipeline and the open-source GitHub workflow:

1. Direct Pushes to Main: The Google-internal repository changes are pushed directly to main via copybara-service automation.
2. Formatting Bypassed: This automated export/sync pipeline often bypasses or incorrectly formats Python files, neglecting rules specified in .pre-commit-config.yaml (such as Google-style pyink formatting or isort sorting).
3. Failing Checks on Main: Direct pushes trigger the Pre-commit Checks on push. Since style violations are present, the CI check fails (resulting in 90+ informational failures on main), but since it's a direct push, it doesn't block the commit itself.
4. Blocking PR Contributors: When external contributors open a PR touching any files, the workflow runs on the pull_request event. Because the pre-commit action runs --all-files, it runs on the entire repo including the misconfigured files on main, failing the contributor's PR CI check despite their own changes being perfectly formatted.

2. Legitimacy Analysis

• Status: Legitimate Bug / Infrastructure Flaw
• Evidence:
  • CI execution uses pre-commit.yml, running pre-commit/action@v3.0.1 (which defaults to scanning --all-files).
  • Strict formatters are enforced in .pre-commit-config.yaml (isort, pyink).
  • Example failures occur in:
    • base_llm_flow.py
    • basic.py
    • gemini_llm_connection.py
    • test_base_llm_flow.py
    • test_gemini_llm_connection.py
  • This is verified by PR #5962, where the author successfully resolves the current failure by running manual formatting on those specific files.

3. Fix Recommendation

• Recommendation: Should Fix (High Priority) / Pipeline Configuration Fix
• Rationale:
  • Impact: High. It adds significant friction to external collaboration. Contributors find their PRs blocked by unrelated style violations on the main branch.
  • Solution Strategy:
    1. Short-Term Workaround: Merge PR #5962 to immediately clean formatting in current files and unblock all pending and newly opened PRs.
    2. Long-Term Corrective Action: Update Google's internal Piper/Copybara sync pipeline to automatically execute isort and pyink formatting on outgoing Python files before pushing them to GitHub.
    3. Alternative CI Refactoring: Alternatively, the pre-commit workflow could be refactored to limit execution to changed files only on Pull Requests (e.g. using extra_args). However, correcting formatting at the Copybara boundary is the preferred architectural solution to maintain clean code and prevent style drift.

4. Existing Pull Requests

• Linked PR: Pull Request #5962 - fix: Python formatting (State: open)
• PR URL: fix: Python formatting #5962
• Analysis: Opened by the same author to fix the current formatting failures in the repository by running isort and pyink on the 5 affected files. It successfully restores formatting cleanliness but is only an immediate fix; future Copybara synchronization commits could re-introduce formatting discrepancies.

---

Executive Summary

1. What is broken? Style checks in GitHub CI fail on external PRs because direct main branch syncs via copybara-service bypass style formatting, and pre-commit scans all files in the repository.
2. Is the issue legitimate? Yes, it is a legitimate infrastructure issue that blocks external contributors from successfully passing pre-commit CI validations.
3. Should we fix it? Yes, High Priority. The immediate files should be reformatted by merging PR #5962, and the Copybara pipeline should be configured to run formatters on outgoing code.
4. Is there a linked PR that fixes this issue? Yes, PR #5962 resolves the immediate styling issue, currently awaiting review from maintainers.

---

Summary of Work Done

• Retrieved issue details for GitHub Issue pre-commit check frequently fails on Copybara pushes to main, blocking external contributors #5963.
• Searched active PRs and retrieved PR fix: Python formatting #5962 details.
• Inspected the repository's .pre-commit-config.yaml and pre-commit workflow .github/workflows/pre-commit.yml.
• Conducted root cause analysis on how copybara-service direct pushes create a discrepancy with --all-files pre-commit checks on external PR branches.
• Produced a high-quality read-only investigation report detailing results and recommendations.