Skip to content

fix: delete unused datastore terraform files in agentic_rag projects#797

Merged
eliasecchig merged 1 commit intomainfrom
fix/rag-datastore-conditional-files
Feb 17, 2026
Merged

fix: delete unused datastore terraform files in agentic_rag projects#797
eliasecchig merged 1 commit intomainfrom
fix/rag-datastore-conditional-files

Conversation

@eliasecchig
Copy link
Collaborator

Summary

  • Delete datastore-specific terraform files that don't match the selected --datastore flag
  • Fix Makefile template conditional nesting for Infrastructure Setup section

Problem

Generated agentic_rag projects included both vertex_ai_search_* and vector_search_* terraform files regardless of which --datastore was selected. The Jinja2 conditionals rendered file contents as empty, but the empty files themselves remained in the project, causing terraform to pick them up and deploy conflicting infrastructure.

Additionally, the Makefile template had the Infrastructure Setup section nested inside an elif for datastore_type == "vertex_ai_search", making it unavailable for vertex_ai_vector_search projects.

Changes

  • agent_starter_pack/cli/utils/template.py: Add 13 entries to CONDITIONAL_FILES mapping each datastore-specific terraform file (both top-level and dev/) to its datastore type condition. Files for the non-selected datastore are deleted during project generation.
  • agent_starter_pack/base_templates/python/Makefile: Split elif cookiecutter.cicd_runner != 'skip' into a separate if block so the Infrastructure Setup section is independent of the datastore conditional.

Both vertex_ai_search and vector_search terraform files were being
included in generated agentic_rag projects regardless of the selected
--datastore flag. The Jinja2 conditionals rendered the file contents
as empty but the files themselves remained.

Add conditional file deletion entries for all datastore-specific
terraform files so only the selected datastore's files are kept.

Also fix Makefile template where the Infrastructure Setup section
was nested inside an elif for datastore_type instead of being a
separate conditional block for cicd_runner.
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @eliasecchig, 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 addresses issues in agentic_rag project generation related to Terraform files and Makefile conditionals. Previously, generated projects would include unnecessary datastore-specific Terraform files, leading to potential conflicts. Additionally, the Makefile's infrastructure setup section was incorrectly nested, making it unavailable for certain datastore configurations. The changes ensure that only relevant Terraform files are included and that the Makefile's infrastructure setup is correctly accessible, improving the reliability and correctness of generated projects.

Highlights

  • Terraform File Deletion: Implemented logic to delete datastore-specific Terraform files that do not match the chosen --datastore flag during project generation, preventing conflicting infrastructure deployments.
  • Makefile Conditional Fix: Corrected the conditional nesting in the Makefile template to ensure the Infrastructure Setup section is always available for projects where a CI/CD runner is not skipped, regardless of the datastore type.
Changelog
  • agent_starter_pack/base_templates/python/Makefile
    • Modified the Jinja2 conditional logic to separate the cicd_runner check from the datastore type check, ensuring the Infrastructure Setup section is always rendered when a CI/CD runner is active.
  • agent_starter_pack/cli/utils/template.py
    • Added 13 new entries to CONDITIONAL_FILES to enable conditional deletion of datastore-specific Terraform files based on the selected datastore type.
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 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 counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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.

@eliasecchig eliasecchig merged commit c0f744b into main Feb 17, 2026
39 of 40 checks passed
Copy link
Contributor

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

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 effectively addresses two issues in agentic_rag project generation. The Makefile conditional logic is corrected to ensure the Infrastructure Setup section is always available when required, and the new conditional file logic in template.py correctly removes unused datastore-specific Terraform files. The changes are well-implemented. I have one suggestion to refactor the new additions in template.py for improved readability and maintainability.

Comment on lines +126 to +165
# Datastore-specific terraform files (vertex_ai_search vs vertex_ai_vector_search)
"deployment/terraform/vertex_ai_search.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_search"
),
"deployment/terraform/vertex_ai_search_variables.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_search"
),
"deployment/terraform/vertex_ai_search_github.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_search"
),
"deployment/terraform/dev/vertex_ai_search.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_search"
),
"deployment/terraform/dev/vertex_ai_search_variables.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_search"
),
"deployment/terraform/vector_search.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/vector_search_variables.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/vector_search_github.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/vector_search_iam.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/vector_search_service_accounts.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/dev/vector_search.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/dev/vector_search_variables.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
"deployment/terraform/dev/vector_search_iam.tf": (
lambda c: c.get("datastore_type") == "vertex_ai_vector_search"
),
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

To improve readability and reduce code duplication, you can use dict.fromkeys combined with dictionary unpacking (**) to assign the same conditional lambda to multiple files. This makes the code more concise and easier to maintain if the condition needs to be updated in the future.

# Datastore-specific terraform files (vertex_ai_search vs vertex_ai_vector_search)
**dict.fromkeys(
    (
        "deployment/terraform/vertex_ai_search.tf",
        "deployment/terraform/vertex_ai_search_variables.tf",
        "deployment/terraform/vertex_ai_search_github.tf",
        "deployment/terraform/dev/vertex_ai_search.tf",
        "deployment/terraform/dev/vertex_ai_search_variables.tf",
    ),
    lambda c: c.get("datastore_type") == "vertex_ai_search",
),
**dict.fromkeys(
    (
        "deployment/terraform/vector_search.tf",
        "deployment/terraform/vector_search_variables.tf",
        "deployment/terraform/vector_search_github.tf",
        "deployment/terraform/vector_search_iam.tf",
        "deployment/terraform/vector_search_service_accounts.tf",
        "deployment/terraform/dev/vector_search.tf",
        "deployment/terraform/dev/vector_search_variables.tf",
        "deployment/terraform/dev/vector_search_iam.tf",
    ),
    lambda c: c.get("datastore_type") == "vertex_ai_vector_search",
),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant