Skip to content

feat: auto-detect depth_level from committed baseline#34

Open
ivanmilevtues wants to merge 11 commits into
mainfrom
feat/depth-auto-detect
Open

feat: auto-detect depth_level from committed baseline#34
ivanmilevtues wants to merge 11 commits into
mainfrom
feat/depth-auto-detect

Conversation

@ivanmilevtues

Copy link
Copy Markdown
Member

What

When depth_level is empty (the new default), the action reads metadata.depth_level from the committed .codeboarding/analysis.json:

  • Sync mode: from the working-tree checkout
  • Review mode: from the PR base SHA via git show

Falls back to 2 when no baseline exists or the field is missing/unparseable. An explicit depth_level input always overrides auto-detection.

Why

Consumers currently hardcode depth_level: '2' in their sync workflows. If the committed baseline was generated at a different depth, this mismatch either forces an unnecessary full regeneration or silently uses the wrong depth. Auto-detection eliminates this — the workflow stays in sync with the baseline automatically.

Changes

  • action.yml: input default changed from '2' to '' (auto)
  • New Resolve analysis depth step after checkout, before analysis
  • All 12 downstream references (cache keys, env vars, validate-base) now use steps.resolve_depth.outputs.depth
  • Guard validation updated to accept empty

When depth_level input is empty (new default), the action reads
metadata.depth_level from the committed .codeboarding/analysis.json:
- sync mode: from the working-tree checkout
- review mode: from the PR base SHA via git show

Falls back to 2 when no baseline exists or the field is missing.
An explicit depth_level input always overrides auto-detection.
@codeboarding-review

codeboarding-review Bot commented Jun 15, 2026

Copy link
Copy Markdown

Architecture review · no architectural changes

graph LR
    n_Workflow_Controller["Workflow Controller"]
    n_Structural_Analysis_Engine["Structural Analysis Engine"]
    n_Developer_Experience_DevEx_Layer["Developer Experience #40;DevEx#41; Layer"]
    n_Telemetry_Integration_Gateway["Telemetry #amp; Integration Gateway"]
    n_Workflow_Controller -- "Triggers the analysis process and passes enviro…" --> n_Structural_Analysis_Engine
    n_Structural_Analysis_Engine -- "Provides rendered diagrams and diffs for PR com…" --> n_Developer_Experience_DevEx_Layer
    n_Workflow_Controller -- "Sends execution status and health check results" --> n_Telemetry_Integration_Gateway
    n_Developer_Experience_DevEx_Layer -- "Forwards user-initiated feedback and interactio…" --> n_Telemetry_Integration_Gateway
    classDef added fill:#1f883d,stroke:#0b5d23,color:#ffffff;
    classDef modified fill:#bf8700,stroke:#7d4e00,color:#ffffff;
    classDef deleted fill:#cf222e,stroke:#82071e,color:#ffffff,stroke-dasharray:5 3;
Loading

Colors indicate component changes compared to main: 🟩 Added · 🟨 Modified · 🟥 Removed


Explore this PR’s architecture in your browser or VS Code.

codeboarding-action · run 27549876297

Comment thread action.yml Outdated
DEPTH=2
if [ "$MODE" = "sync" ]; then
if [ -f "$TARGET_REPO/.codeboarding/analysis.json" ]; then
DEPTH=$(python3 -c "import json; print(json.load(open('$TARGET_REPO/.codeboarding/analysis.json')).get('metadata',{}).get('depth_level',2))" 2>/dev/null || echo 2)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is the important line.

@ivanmilevtues ivanmilevtues self-assigned this Jun 15, 2026

@ivanmilevtues ivanmilevtues left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Sync works on your main branch (Configurable)

For a review/PR (the user decides on what action), we will look for the first PR in the history which has anlaysis.json and do iterative on it, if not a full analysis.

The result will be uploaded and the link is in the description for now.

Comment thread action.yml
REPO_NAME: ${{ github.event.repository.name }}
RUN_ID_BASE: ${{ github.run_id }}-${{ github.run_attempt }}-base
DEPTH: ${{ inputs.depth_level }}
DEPTH: ${{ steps.resolve_depth.outputs.depth }}

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

this is important change

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.

Iiuc, it's either the default from before or what the user provides as input?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes

Comment thread action.yml
- name: Upload PR analysis artifact
if: steps.guard.outputs.skip != 'true' && steps.guard.outputs.mode == 'review'
id: upload_review_artifact
uses: actions/upload-artifact@v4

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

THis is the other important thing

Comment thread action.yml
OWNER_REPO: ${{ github.repository }}
RUN_ID: ${{ github.run_id }}
RUN_ATTEMPT: ${{ github.run_attempt }}
run: |

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is the imporant new thing where we upload the artifacts: analysis.json and manifest.json (contains base refs)

Comment thread action.yml
# Use the newest analysis.json reachable by walking backwards through
# the PR head branch ancestry. If the PR branch is a->b->c->d and master
# is a->b->m1->m2, this deliberately searches d,c,b,a — not m2,m1,b,a.
while IFS= read -r candidate; do

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is the new thing which resolves the proper analysis.json to be based on going backwards in time as it says above. IT goes back on the branch that is about to be merged.

@Svilen-Stefanov Svilen-Stefanov 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.

Apart from the other questions, I have two other things I'm wondering:

  • do we want to make the action configurable to either run on every commit or run only when prompted?
  • what's the retention time of the artifacts and do they get lost after deleting a branch? I suppose one downside of this is the fact that we loose information sooner than later but I think it's okay for now.

Comment thread scripts/build_cta.py
head_sha: str,
base_sha: str,
*,
pr: str = "",

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.

One thing that I noticed here - this design suggests that we cannot compare branches without PRs, right? That might change the way we show things on the webview as well

Comment thread scripts/engine_adapter.py

def _supported_depth(metadata: dict) -> int | None:
depth = _metadata_depth(metadata)
return depth if depth in range(1, 4) else None

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.

Should we make this global to be easier to see?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

hmm, probably if you have license this should be fine and there shouldn't be any limit

Comment thread scripts/engine_adapter.py Outdated
Comment thread .gitignore
*.py[cod]

# CodeBoarding generated cache/log artifacts
.codeboarding/static_analysis.pkl

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.

Why are we removing only these? I suppose we should either keep all of these ignored or remove them all or do we treat the pkl and the other files (e.g healh) differently?
I suppose we want to still keep them all ignored and only the action commits them in the main branch?

One strange thing for me with this is that if they are ignored, someone will think they could be removed from main overall. If they are not, they could be committed. I guess they should generally remain ignored?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

fair probably, then the extension will need to force add and push them

Comment thread action.yml
REPO_NAME: ${{ github.event.repository.name }}
RUN_ID_BASE: ${{ github.run_id }}-${{ github.run_attempt }}-base
DEPTH: ${{ inputs.depth_level }}
DEPTH: ${{ steps.resolve_depth.outputs.depth }}

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.

Iiuc, it's either the default from before or what the user provides as input?

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.

2 participants