code-review-graph connects to GitHub Actions: incremental graph building, PR review and cache debugging

code-review-graph is connected to GitHub Actions: incremental graph building, PR review and cache debugging, covering configuration, verification, permission boundaries, failure rollback and long-term maintenance.

This tutorial by code-review-graph only deals with the specific task in the title. The project uses Tree-sitter to build a local structure map and narrows the code review context through MCP; the key to CI is incremental mapping, cache boundaries and minimum permissions.

All the following operations are first placed in the test repository, test account or service that listens only on the loopback interface. The domain name, username, path and key in the command are placeholders and need to be replaced before execution.

Why PR Reviews Need Persistent Code Maps

This section addresses “Why PR reviews need to persist code maps.” First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For code-review-graph, the basis for judgment is: the project uses Tree-sitter to build a local structure graph and narrows the code review context through MCP; the key to CI is incremental mapping, cache boundaries and minimum permissions. Don’t accidentally open more permissions at this stage.

1
2
python --version
pipx --version

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Python 3.10 and pipx environment preparation

Process in the following order:

  1. Read the actual version and current configuration.
  2. Change only one setting relevant to this section.
  3. Run a read-only or revocable request.
  4. Check logs, exit codes, and final files.
  5. Revert the previous modification if it fails.
1
pipx install code-review-graph

The completion criterion here is not that the interface appears, but that “Python 3.10 and pipx environment preparation” has reproducible results.

What directory should be executed in the first build?

What to check Acceptable performance Signals that you need to stop
What directory should be executed in the first build Clear input and output scope Automatically expand to other projects or accounts
Permissions Get only the permissions you need to complete the task Require administrator rights or full key
Log Failed to locate and has been desensitized Token, Cookie or private text appears
Rollback Can restore the previous state Modifications are irreversible and there is no backup
1
code-review-graph build

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

Install MCP configuration for Codex only

Prepare a success sample and a failure sample around “Install MCP configuration for Codex only”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1
code-review-graph install --platform codex

It is recommended to record the following four items:

  • Pre-execution version or Git commit.
  • Actual input, no secret value recorded.
  • Observable output, status code or diff.
  • Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

Check whether the generated graph covers the target language

This section addresses “checking whether the generated graph covers the target language”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For code-review-graph, the basis for judgment is: the project uses Tree-sitter to build a local structure graph and narrows the code review context through MCP; the key to CI is incremental mapping, cache boundaries and minimum permissions. Don’t accidentally open more permissions at this stage.

1
code-review-graph build

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Design trigger conditions for GitHub Actions

Process in the following order:

  1. Read the actual version and current configuration.
  2. Change only one setting relevant to this section.
  3. Run a read-only or revocable request.
  4. Check logs, exit codes, and final files.
  5. Revert the previous modification if it fails.
1
git diff --name-only origin/main...HEAD

The completion criterion here is not that the interface appears, but that “designing trigger conditions for GitHub Actions” has repeatable results.

Which files should the cache key be bound to?

What to check Acceptable performance Signals that you need to stop
Which files should the cache key be bound to? Clear input and output scope Automatically expand to other projects or accounts
Permissions Get only the permissions you need to complete the task Require administrator rights or full key
Log Failed to locate and has been desensitized Token, Cookie or private text appears
Rollback Can restore the previous state Modifications are irreversible and there is no backup
1
git rev-parse HEAD

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

How to reduce permissions of PR from Fork

Prepare a success sample and a failure sample around “How PR from Fork reduces permissions”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1
git status --short

It is recommended to record the following four items:

  • Pre-execution version or Git commit.
  • Actual input, no secret value recorded.
  • Observable output, status code or diff.
  • Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

Return to normal git diff when the map is invalid

This section solves the problem of “returning to normal git diff when the map fails”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For code-review-graph, the basis for judgment is: the project uses Tree-sitter to build a local structure graph and narrows the code review context through MCP; the key to CI is incremental mapping, cache boundaries and minimum permissions. Don’t accidentally open more permissions at this stage.

1
git diff --stat origin/main...HEAD

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Reproduce the difference between local and CI results

Process in the following order:

  1. Read the actual version and current configuration.
  2. Change only one setting relevant to this section.
  3. Run a read-only or revocable request.
  4. Check logs, exit codes, and final files.
  5. Revert the previous modification if it fails.
1
code-review-graph build

The completion criterion here is not that the interface appears, but that “reproducing the difference between local and CI results” has repeatable results.

Rebuild cache after upgrading parser

What to check Acceptable performance Signals that you need to stop
Rebuild the cache after upgrading the parser Clear input and output scope Automatically expand to other projects or accounts
Permissions Get only the permissions you need to complete the task Require administrator rights or full key
Log Failed to locate and has been desensitized Token, Cookie or private text appears
Rollback Can restore the previous state Modifications are irreversible and there is no backup
1
2
pipx upgrade code-review-graph
code-review-graph build

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

What should be included in the final evidence for a PR review?

Prepare a success sample and a failure sample around “what should be included in the final evidence for a PR review.” Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1
git diff --check

It is recommended to record the following four items:

  • Pre-execution version or Git commit.
  • Actual input, no secret value recorded.
  • Observable output, status code or diff.
  • Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

Reduce the mapping directory in Monorepo

This section addresses “Reducing the mapping directory in Monorepo”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For code-review-graph, the basis for judgment is: the project uses Tree-sitter to build a local structure graph and narrows the code review context through MCP; the key to CI is incremental mapping, cache boundaries and minimum permissions. Don’t accidentally open more permissions at this stage.

1
git diff --name-only origin/main...HEAD

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Locate files that failed to be parsed by Tree-sitter

Process in the following order:

  1. Read the actual version and current configuration.
  2. Change only one setting relevant to this section.
  3. Run a read-only or revocable request.
  4. Check logs, exit codes, and final files.
  5. Revert the previous modification if it fails.
1
code-review-graph build

The completion criterion here is not the appearance of the interface, but the reproducible results of “locating files that failed to be parsed by Tree-sitter”.

Bind the map product to the source code version

What to check Acceptable performance Signals that you need to stop
Bind map products to source code versions Clear input and output scope Automatically expand to other projects or accounts
Permissions Get only the permissions you need to complete the task Require administrator rights or full key
Log Failed to locate and has been desensitized Token, Cookie or private text appears
Rollback Can restore the previous state Modifications are irreversible and there is no backup
1
git rev-parse HEAD

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

Compare the context overhead before and after enabling the graph

Prepare a success sample and a failure sample around “Comparing the context overhead before and after enabling the graph”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1
git diff --stat origin/main...HEAD

It is recommended to record the following four items:

  • Pre-execution version or Git commit.
  • Actual input, no secret value recorded.
  • Observable output, status code or diff.
  • Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

code-review-graph FAQ

Is it possible to skip the test environment and use code-review-graph directly in the official project?

Not recommended. Complete at least one minimal success request, one intentional failure, and one recovery drill first.

The code-review-graph command can be run but the result is incorrect. Where to check first?

First check the input range, actual effective configuration and upstream response, and then check the model summary. A normal process does not mean that the business results are correct.

How to prevent code-review-graph keys or tokens from entering Git?

Use system environment variables, secret management, or configuration files outside the project, and search the diff before committing. Keys must be rotated after a breach is discovered.

What is most likely to be missed when upgrading code-review-graph?

It is most easy to miss configuration format, default listening address, permission scope and cache compatibility. Save the version and verification samples before upgrading.

code-review-graph acceptance issues

Upon completion you should be able to answer the following questions:

  • Which exact version are you using?
  • Which directories, ports, accounts and external services can be accessed?
  • How to return the successful result to the original data or Git diff?
  • When the upstream fails, will it report an error, retry, or switch?
  • Is it possible that the key appears in logs or history?
  • How to return to the pre-modification state within ten minutes?

If any of these cannot be answered, code-review-graph is still in trial status and should not be extended permissions or plugged into production automation.