Summary
When a workspace: entry references the same ADO repository that is already checked out as self, the compiled pipeline produces two checkout: steps that resolve to the same directory (s/<repo-name>). The second checkout overwrites the first, causing downstream steps (e.g. "Verify pipeline integrity") to fail because files from the self branch are replaced by the workspace branch.
Reproduction
- Create an agent
.md whose workspace: list includes the repo that also hosts the pipeline YAML (i.e. the self repo).
- Compile with
ado-aw compile.
- Run the pipeline from a feature branch that has changes not yet on
main.
- The "Verify pipeline integrity" step fails:
Error: Failed to read pipeline file: component-governance.lock.yml Caused by: No such file or directory (os error 2)
Root Cause
In ADO multi-repo checkout, both checkout: self and checkout: repo-<self-repo-name> resolve to the same directory s/<repo-name>. The second checkout runs git clean -ffdx then checks out its configured ref (typically main), wiping files that only exist on the feature branch.
Observed in: Build 604639
checkout: self → s/azure-devops-agentic-pipelines @ feature/failure-summary-agent ✅
checkout: repo-azure-devops-agentic-pipelines → s/azure-devops-agentic-pipelines @ main — overwrites self ❌
Expected Behavior
The compiler should detect when a workspace:/checkout: entry references the same underlying repo as self and either:
- Emit a compile-time error/warning explaining the collision, or
- Automatically skip the redundant checkout (since
self already provides access), or
- Auto-assign a distinct
path: to the workspace checkout to avoid the directory collision (e.g. s/repo-<alias> instead of s/<repo-name>)
Suggested Fix Location
src/compile/common.rs — validate_checkout_list() or the checkout generation logic. The compiler already has access to the self repo identity and the workspace repo list at compile time, so a comparison is straightforward.
Environment
- ado-aw version: v0.26.0
- Pipeline: OS+Tooling CG Purview (
component-governance.lock.yml)
- Agent pool: AZS-1ES-L-MMS-ubuntu-22.04
- OS: Ubuntu 22.04
Summary
When a
workspace:entry references the same ADO repository that is already checked out asself, the compiled pipeline produces twocheckout:steps that resolve to the same directory (s/<repo-name>). The second checkout overwrites the first, causing downstream steps (e.g. "Verify pipeline integrity") to fail because files from theselfbranch are replaced by the workspace branch.Reproduction
.mdwhoseworkspace:list includes the repo that also hosts the pipeline YAML (i.e. theselfrepo).ado-aw compile.main.Error: Failed to read pipeline file: component-governance.lock.yml Caused by: No such file or directory (os error 2)Root Cause
In ADO multi-repo checkout, both
checkout: selfandcheckout: repo-<self-repo-name>resolve to the same directorys/<repo-name>. The second checkout runsgit clean -ffdxthen checks out its configured ref (typicallymain), wiping files that only exist on the feature branch.Observed in: Build 604639
checkout: self→s/azure-devops-agentic-pipelines@feature/failure-summary-agent✅checkout: repo-azure-devops-agentic-pipelines→s/azure-devops-agentic-pipelines@main— overwrites self ❌Expected Behavior
The compiler should detect when a
workspace:/checkout:entry references the same underlying repo asselfand either:selfalready provides access), orpath:to the workspace checkout to avoid the directory collision (e.g.s/repo-<alias>instead ofs/<repo-name>)Suggested Fix Location
src/compile/common.rs—validate_checkout_list()or the checkout generation logic. The compiler already has access to the self repo identity and the workspace repo list at compile time, so a comparison is straightforward.Environment
component-governance.lock.yml)