Skip to content

Triage Agent: Use firestore DB instead of GCS bucket - #6224

Draft
AdarshK15 wants to merge 7 commits into
GoogleCloudPlatform:developfrom
AdarshK15:fix-triage-agent
Draft

Triage Agent: Use firestore DB instead of GCS bucket#6224
AdarshK15 wants to merge 7 commits into
GoogleCloudPlatform:developfrom
AdarshK15:fix-triage-agent

Conversation

@AdarshK15

@AdarshK15 AdarshK15 commented Aug 28, 2026

Copy link
Copy Markdown
Member

Summary

This PR updates the test files to support the newly migrated Failure Triage Agent architecture.

The agent backend has been updated to use a Firestore DB instead of GCS buckets to support RAG, vector search, and human feedback. The resulting diagnostic report has also been moved from an GCS bucket text file to a dedicated Dashboard page.

To support this, updated trigger_failure_triage_agent.yml to inject the new database URL variables, and centralized all the triage agent secrets.

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request completes the migration of the Failure Triage Agent backend from GCS buckets to Firestore. This change enables more robust data handling and integrates with a new dashboard for diagnostic reports. The changes involve updating the agent's initialization logic to fetch necessary secrets natively and cleaning up the build pipeline configurations to remove obsolete dependencies.

Highlights

  • Architecture Migration: Migrated the Failure Triage Agent from using GCS buckets to Firestore DB to support advanced features like RAG, vector search, and human feedback.
  • Configuration Updates: Updated trigger_failure_triage_agent.yml to dynamically retrieve new configuration secrets (Firestore URL, UI URL) and centralized secret management.
  • Build System Cleanup: Removed deprecated GCS-related environment variables and secrets from multiple Cloud Build configuration files across the repository.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the daily integration tests by centralizing the retrieval of Failure Triage Agent secrets. Instead of passing these secrets through environment variables and extra-vars across dozens of Cloud Build YAML files, they are now retrieved natively via gcloud within the Ansible tasks. Additionally, the triage pipeline was updated to poll Firestore instead of GCS for build status, and the final report link now points to a dedicated UI URL. Feedback on the changes includes resolving potential AnsibleUndefinedVariable errors when triage tasks are skipped, and extracting a complex inline shell script into a separate file to improve maintainability.

@AdarshK15

Copy link
Copy Markdown
Member Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the Failure Triage Agent integration across daily tests by replacing inline bash scripts with dedicated Python scripts (trigger_triage_agent.py and wait_for_triage_agent.py) and retrieving core architecture secrets natively via gcloud in Ansible. It also updates the diagnostic report link to point to a web UI URL. The review feedback highlights several critical improvements: explicitly validating PROJECT_ID in the Ansible task to prevent silent failures, ensuring PROJECT_ID is consistently passed to the runner container's environment across all build configurations (such as batch.yaml and gke.yaml), and adding timeouts and robust error handling (catching URLError and JSONDecodeError) to the new Python scripts to prevent indefinite hangs and unhandled crashes.

Comment thread tools/cloud-build/daily-tests/builds/batch.yaml
Comment thread tools/cloud-build/daily-tests/builds/gke.yaml
Comment thread tools/cloud-build/trigger_triage_agent.py
Comment thread tools/cloud-build/wait_for_triage_agent.py
@AdarshK15

Copy link
Copy Markdown
Member Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the failure triage agent pipeline across daily test builds by retrieving secrets natively via gcloud in Ansible rather than passing them through Cloud Build configuration files. It also replaces shell-based trigger and wait mechanisms with Python scripts (trigger_triage_agent.py and wait_for_triage_agent.py) that interface with Firestore. The review identified several issues, including a potential playbook crash due to referencing triage_ui_url outside of the conditional block, inconsistent secret naming conventions, fragile hardcoded index bindings, and potential permission errors when executing the Python scripts directly. Additionally, the feedback points out robust error-handling improvements in the wait script to prevent masking HTTP errors and to safely parse Firestore documents without raising AttributeError.

Comment thread tools/cloud-build/wait_for_triage_agent.py
Comment thread tools/cloud-build/wait_for_triage_agent.py Outdated
@AdarshK15

Copy link
Copy Markdown
Member Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the daily test failure triage agent pipeline. It simplifies the Cloud Build configurations by removing several secret environment variables and extra-vars, shifting the responsibility of retrieving these secrets natively to the Ansible playbook via gcloud. It also replaces inline bash scripts in the playbook with two new Python scripts (trigger_triage_agent.py and wait_for_triage_agent.py) and updates the status polling mechanism to use Firestore instead of GCS. Feedback on the changes highlights that the Ansible playbook's error-handling logic for secret retrieval needs to be more robust, as ignore_errors: true prevents the task from being marked as failed even if individual secrets fail to load. Additionally, adding docstrings and comments to the new Python scripts is recommended to improve maintainability.

Comment thread tools/cloud-build/trigger_triage_agent.py
Comment thread tools/cloud-build/wait_for_triage_agent.py
@AdarshK15

Copy link
Copy Markdown
Member Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the failure triage agent integration in the daily tests. It replaces the static passing of triage configuration secrets through Cloud Build manifests with dynamic, native secret retrieval via gcloud within the Ansible playbooks. Additionally, the inline bash scripts for triggering and waiting for the triage agent have been replaced with dedicated Python scripts (trigger_triage_agent.py and wait_for_triage_agent.py) that interact with the triage agent's Cloud Run service and poll Firestore for status updates. Feedback on these changes includes standardizing the naming conventions of the retrieved secrets for consistency and improving the robustness of subprocess calls in the Python scripts by passing arguments as separate list elements.

Comment thread tools/cloud-build/wait_for_triage_agent.py Outdated
@AdarshK15

Copy link
Copy Markdown
Member Author

/gemini review

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the daily-test Failure Triage Agent pipeline by retrieving secrets natively via gcloud within Ansible and replacing inline bash scripts with Python scripts (trigger_triage_agent.py and wait_for_triage_agent.py). It also updates the diagnostic report link to point to a UI-based URL. The review feedback highlights a critical issue where PROJECT_ID and BUILD_ID are missing from the runner container environments in several GKE daily-test build files, which would cause the triage agent to be silently skipped. Additionally, the reviewer suggests simplifying the complex Jinja2 filters used to check for secret retrieval failures in the Ansible tasks.

@AdarshK15 AdarshK15 added the release-chore To not include into release notes label Sep 3, 2026
@AdarshK15 AdarshK15 self-assigned this Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-chore To not include into release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant