Pre-Deployment App Graph with Git Integration #142
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
nithyatsu
reviewed
Feb 2, 2026
|
|
||
| 5. **Given** a Bicep file using the Radius Bicep extension types, **When** I run `rad app graph app.bicep`, **Then** the graph correctly identifies Radius-specific resource types and their relationships. | ||
|
|
||
| --- |
Contributor
There was a problem hiding this comment.
Would we have to resolve the environment in use and get to the details of in the graph? For instance, Radius.Data/store might be rendering a postgresSQL in one environment while it might render cosmosDB in another depending on env--> recipepack-->recipe resolution.
nithyatsu
reviewed
Feb 2, 2026
| 5. **Given** a graph exported to markdown, **When** viewed in GitHub, **Then** the Mermaid diagram renders as a visual flowchart with distinct shapes for resource types (containers as rectangles, gateways as diamonds, databases as cylinders). | ||
|
|
||
| 6. **Given** two app graphs from different commits, **When** I diff them, **Then** the diff is computed from JSON (not Markdown), and added/removed/modified resources are clearly identified. | ||
|
|
Contributor
There was a problem hiding this comment.
Would this correspond to a cli command too?
nithyatsu
reviewed
Feb 2, 2026
| 1. **Bicep Compiler Integration**: Should we use the official Bicep CLI for parsing, or implement a lightweight parser? Trade-off: accuracy vs. dependency management. **Recommendation**: Use official Bicep CLI per Constitution Principle VII (Simplicity Over Cleverness). | ||
|
|
||
| 2. ~~**Graph Storage**: Should generated graphs be committed to the repo (e.g., `app-graph.json`)? Trade-off: visibility vs. repo noise.~~ **RESOLVED**: Yes, graphs are committed to `.radius/app-graph.json`. This enables lightweight GitHub Action (reads from git history, no tooling required) and provides auditable graph evolution. | ||
|
|
Contributor
There was a problem hiding this comment.
Would we not want to consider databases that can help make diff queries / genral queries easier? It does look like GitHub Actions artifacts + JSON query can help, But claude/ copilot also brought up some lightweight database options:
(1) SQLite file in repo, (2) Turso (SQLite edge), (3) Supabase (Postgres) (AI recommended for diff optimizations + json handling but paid after first 7 days rate limits free version), (4) GitHub Actions artifacts + JSON query, (5) SQLite + GH Cache (** AI recommended oevrall **) (6) construct each time the page is accessed
nithyatsu
reviewed
Feb 2, 2026
| 4. **Diff Visualization**: What's the preferred format for showing diffs in PR comments—table-based, Mermaid side-by-side, or unified text diff? | ||
|
|
||
| 5. **Parameter Handling**: How should we handle Bicep parameters without a params file—use defaults, require params, or mark as "unknown"? | ||
|
|
Contributor
There was a problem hiding this comment.
A few more questions:
- Q: Where would the graph be displayed? On the README.md in the app.bicep repo and in the PR home pages?
- Q: How should the system handle unresolvable module references? → A: Show partial graph with warning + display unresolved modules as placeholder nodes (taking a best effort approach than display error in case the full picture cannot be resolved)
- Q: can we assume the repo has app.bicep checked in, and the workflow that generates graphs can query radius? Would this be the repo radius?
- Q: What extent of info should the graph capture for specific resources that we can know only in the context of which environment the app.bicep is invoked in? ( environment -> recipe-pack--> recipe resolution dependent resources) Would we display "Radius.Data/database" Or get to the specifics such as postgreSQL?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Feature Specification: Git App Graph Preview
specs/001-git-app-graph-preview/spec.md) describing static app graph generation from Bicep files, git metadata enrichment, diff-friendly output formats, GitHub PR integration, and related requirements, user stories, edge cases, and success criteria.specs/001-git-app-graph-preview/checklists/requirements.md) to validate the completeness and readiness of the specification before planning.