Can Gemini Enterprise GitHub connector support a read-only review/search app for a private GitHub repository?

[英明_久保]

I’m evaluating Gemini Enterprise / AI Applications with the GitHub connector.

Use case:
I want to create a read-only review/search assistant for a specific private repository under a GitHub Organization. The goal is not to allow the app to write to GitHub, but only to search and answer questions based on repository content.

Current PoC configuration:

• GitHub Organization private repository
• Custom GitHub App
• GitHub App permissions minimized
  • Contents: Read-only
  • Metadata: Read-only
  • Checks / Commit statuses: No access
  • Issues / Pull requests: not enabled unless required
• Gemini Enterprise / AI Applications GitHub connector
• Entity selected: Repositories only
• Actions: all unselected / skipped
• Search app created and connected to the GitHub data store
• Preview search returns some repository-derived results

Questions:

1. In this configuration, does Gemini Enterprise search the GitHub repository in real time, or does it search only the indexed data in the GitHub connector data store?

2. Is a read-only review/search assistant scoped to a specific private GitHub repository a supported use case for the GitHub connector?

3. If all GitHub Actions are skipped/unselected, can the app perform any write operations such as branch creation, file update, push, pull request update, merge, or issue comments?

4. Does the Repositories entity support file-level exact lookup and file existence checks inside a private repository, or is it intended for semantic search over indexed repository-derived content?

5. If a query references a file that does not exist, the app may still return semantically related documents. Is this expected behavior? Is there a recommended way to perform exact file existence checks?

6. For a read-only repository review assistant, should we use the GitHub connector, Developer Connect, Gemini Code Assist for GitHub, GitHub API, or another architecture?

The intended use is review support and context search only. It is not intended to replace GitHub branch protection/rulesets, CodeRabbit, Gitleaks, or CI checks.

[Neo_Mahlangu]

Hi, your setup is valid, but a few behaviors you’re seeing are by design rather than misconfiguration. I’ll break this down and then propose a cleaner architecture for a read-only review assistant.

---

1) Does Gemini query GitHub in real time?

Short answer: No.

When you connect a GitHub App to a data store in Google Cloud Vertex AI, the system:

• Indexes repository content into a managed data store

• Executes queries against that indexed representation, not GitHub directly

Implications:

• There is latency between repo updates and index freshness

• Queries reflect the last indexed state, not live repository state

If you need real-time guarantees, you must augment with direct GitHub API calls.

---

2) Is a read-only assistant for a private repo supported?

Yes—this is a first-class use case.

Your configuration aligns with intended patterns:

• Private repo

• Minimal GitHub App permissions

• “Repositories” entity only

• Actions disabled

This effectively positions the system as:

Retrieval + reasoning layer over repository content

---

3) Do disabled actions guarantee no writes?

Within Google Cloud Vertex AI and Google AI Studio:

• Disabling actions prevents the model from invoking write operations through the connector

• The platform will not execute mutations (PRs, commits, branches)

However, the stronger guarantee comes from:

• Your GitHub App permissions

If your app is configured as read-only:

• No branch creation

• No file updates

• No PR modifications

So the guarantee is effectively defense-in-depth:

1. Connector actions disabled

2. GitHub App scoped to read-only

---

4) Does “Repositories” support exact file lookups?

Not natively.

The “Repositories” entity is optimized for:

• Semantic search

• Chunked indexing of code and docs

It does not behave like a file system index.

So:

• “Find auth_service.ts” → may return related files

• “Explain authentication logic” → works well

---

5) Why non-existent files return “related” results

This is expected.

The system uses:

• Embedding similarity

• Contextual ranking

So when a file doesn’t exist, it returns:

“Closest semantic matches,” not “no result”

---

6) How to perform exact file existence checks

You need to introduce a deterministic layer, because semantic retrieval cannot guarantee exactness.

Options:

A. GitHub API (most direct)

• GET /repos/{owner}/{repo}/contents/{path}

• Returns 404 if file does not exist

---

B. Indexed manifest (recommended inside Google Cloud)

Create a lightweight index:

• File paths

• Hashes

• Metadata

Store in:

• BigQuery or Firestore

Then:

• Query = exact match → deterministic

• Fallback → semantic search via Gemini

---

7) Recommended architecture (unified, pre-GitHub exposure)

To keep everything inside Google’s ecosystem before going “live,” structure it like this:

---

Layer 1 — Ingestion & Indexing

• GitHub App (read-only)

• Sync → Google Cloud Vertex AI data store

• Parallel extraction:

  • File path manifest

  • Repo metadata

---

Layer 2 — Dual Retrieval System

A. Deterministic Retrieval

• File existence

• Exact path lookup

• Metadata queries

B. Semantic Retrieval

• Code understanding

• Cross-file reasoning

• Documentation synthesis

---

Layer 3 — Orchestration (inside Google)

Use:

• Google AI Studio for:

  • Prompt design

  • Tool routing logic

  • Evaluation

Routing pattern:

• If query looks like exact lookup → deterministic layer

• Else → semantic retrieval

---

Layer 4 — Controlled Interface

Before GitHub exposure:

• Internal UI / API (Cloud Run or similar)

• Enforce:

  • Read-only guarantees

  • Query classification

  • Logging + evaluation

---

Layer 5 — Optional Extensions

• Google Cloud Developer Connect
  For more structured CI/CD-aware integrations

• Gemini Code Assist
  For developer-facing workflows rather than system-level assistants