fix(compile): checkout create-pull-request repositories in the SafeOutputs job

[jamesadevine]

Summary

For a workflow that configures create-pull-request and checks out additional
repositories, ado-aw generates a SafeOutputs job that references every
PR-eligible repository directory but checks out only self.

This leaves the additional repository directories absent in Stage 3. It also
changes Azure Pipelines' placement of self: with only one checkout, self
lives directly at $(Build.SourcesDirectory), while the generated executor
source path assumes the multi-checkout layout under
$(Build.SourcesDirectory)/$(Build.Repository.Name).

As a result, the SafeOutputs job cannot reliably prepare or execute a
multi-repository create-pull-request.

Relationship to #1458

PR #1458 correctly fixed the shallow-checkout failure tracked by #1453. It
staged prepare-pr-base.js in the SafeOutputs job and fetched the target ref
before ado-aw execute.

The remaining gap is narrower:

• create_pr_prepare_repos emits --repo-dir arguments for self and every
  additional checkout.
• build_safeoutputs_job still emits only checkout: self.
• The multi-repository regression test added by fix(compile): emit prepare-pr-base in the SafeOutputs job (#1453) #1458 asserts that the
  --repo-dir arguments are present, but does not assert that corresponding
  checkout steps create those directories.

Minimal reproduction

---
name: Multi-repo PR
description: Opens a pull request in an additional Azure Repos repository
workspace: root
repos:
  - name: Project/tools
    alias: tools
safe-outputs:
  create-pull-request:
    target-branch: main
---

## Objective

Update one file in the `tools` checkout and create a pull request with
`repository: tools`.

Compile the workflow and inspect the generated SafeOutputs job.

Actual generated shape

The job effectively contains:

steps:
  - checkout: self

  # No `checkout: tools`

  - bash: |
      node prepare-pr-base.js \
        --repo-dir "$(Build.SourcesDirectory)" \
        --target-branch main \
        --repo-dir "$(Build.SourcesDirectory)/tools" \
        --target-branch main

  - bash: |
      ado-aw execute \
        --source "$(Build.SourcesDirectory)/$(Build.Repository.Name)/agents/multi-repo-pr.md"

Azure Pipelines jobs have isolated workspaces. The Agent job's tools
checkout is therefore unavailable in SafeOutputs.

Because SafeOutputs has only one checkout:

• $(Build.SourcesDirectory)/tools does not exist.
• self is placed directly at $(Build.SourcesDirectory).
• The nested --source path under $(Build.Repository.Name) does not exist.

The prepare step or executor fails before the proposed PR can be applied.

Expected behavior

Any SafeOutputs variant that executes create-pull-request should check out:

1. self.
2. Every additional unified repos: entry with checkout: true.

Those checkouts must use the same aliases as the Agent job and run before
prepare-pr-base.js and ado-aw execute.

This gives SafeOutputs the same multi-checkout layout assumed by:

• create_pr_prepare_repos;
• CreatePullRequestResult repository resolution; and
• the generated executor source path.

Repositories declared with checkout: false must remain resource-only.

For split approval, additional checkouts should appear only in the
SafeOutputs/SafeOutputs_Reviewed variant whose tool set actually includes
create-pull-request.

Suggested implementation

In build_safeoutputs_job, after checkout_self_step and when
variant.runs_create_pull_request is true, emit the same additional checkout
steps used by the Agent job for every checked-out repository alias.

Keep the current per-repository target-branch resolution and
prepare-pr-base.js invocation unchanged.

Regression tests

Extend the existing issue-1453 compiler coverage with a workflow containing
two additional repositories:

1. Assert the Agent job has:
   • checkout: self
   • checkout: tools
   • checkout: docs
2. Assert the SafeOutputs variant that runs create-pull-request has the same
   three checkout steps before prepare-pr-base.js.
3. Assert the generated executor --source path matches Azure's
   multi-checkout placement of self.
4. Assert a checkout: false repository is not checked out.
5. Assert split-approval emits the additional checkouts only in the variant
   that executes create-pull-request.

An ADO smoke test should create a PR against an additional checkout, since a
hermetic prepare-pr-base.js test cannot detect missing Azure checkout steps.

Affected versions

• Reproduced in v0.45.1.
• Still present on main at 120f6600.
• Still present in the open v0.46.0 release PR chore(main): release 0.46.0 #1530; that release branch has
  no checkout-logic diff from main.

Related

• [aw]: Follow-up to #1413 / #1425: create-pull-request worktree fails — the prepare-pr-base step runs in the Agent job, but the executor runs in the SafeOutputs job (standalone target) #1453
• fix(compile): emit prepare-pr-base in the SafeOutputs job (#1453) #1458

[github-actions]

🏷️ Triaged

Labeled as bug, rust.

Why: The issue reports incorrect compiled YAML output in the SafeOutputs job (missing checkout steps for additional repositories when create-pull-request is configured), which is a bug in the Rust compiler code — specifically build_safeoutputs_job in src/compile/agentic_pipeline.rs. The bug label was already present; rust was added to flag the affected area.

_{Automated triage — a maintainer can adjust labels anytime.}

Generated by Issue Triage for #1731 · 19.1 AIC · ⌖ 5.68 AIC · ⊞ 6.2K · ◷

[jamesadevine]

/plan investigate the legitimacy of this finding and include a new smoke of this behaviour for the executor e2e smoke.

[github-actions]

✅ Issue Plan Maker completed successfully!

[github-actions]

Implementation Plan — #1731: Checkout create-pull-request repositories in the SafeOutputs job

Objective

Ensure the SafeOutputs job emits a checkout: step for every additional repository (from front_matter.checkout) when the variant runs create-pull-request, giving it the same multi-checkout disk layout assumed by create_pr_prepare_repos and ado-aw execute.

---

Finding: Legitimate ✅

The bug is confirmed. In build_safeoutputs_job (src/compile/agentic_pipeline.rs, line 1436), only checkout_self_step is emitted. The block at lines 1477–1488 that activates on variant.runs_create_pull_request correctly calls create_pr_prepare_repos (which references $(Build.SourcesDirectory)/<alias>), but no checkout steps are emitted for those aliases — the directories don't exist.

By contrast, the Agent job builder (lines 848–862) iterates front_matter.checkout and emits a Step::Checkout(CheckoutStep { ... }) for each alias. The SafeOutputs job simply omits this loop.

The existing test_create_pull_request_safeoutputs_prepare_step_covers_all_checkout_repos test only asserts --repo-dir arguments in the prepare-pr-base invocation; it does not assert that corresponding checkout: steps precede it. The gap went undetected.

---

Scope

In scope:

• Emit additional checkout steps in build_safeoutputs_job when variant.runs_create_pull_request
• Respect checkout: false entries (already filtered: front_matter.checkout contains only repos with checkout: true)
• Respect split-approval: additional checkouts only in the variant that runs create-pull-request
• Extend compiler tests (assert checkout steps, not just --repo-dir)
• Add a multi-repo executor e2e scenario in scripts/ado-script/src/executor-e2e/scenarios/create-pull-request.ts

Out of scope:

• Non-create-pull-request tools (they have no checkout dependency in SafeOutputs)
• Changes to create_pr_prepare_repos logic or prepare-pr-base.js
• 1ES / stage / job target variants (same build_safeoutputs_job function; fix propagates automatically)

---

Work Breakdown

• 1. Fix build_safeoutputs_job (src/compile/agentic_pipeline.rs)

  After checkout_self_step and inside the if variant.runs_create_pull_request block (before install_and_download_steps_typed), iterate front_matter.checkout and push Step::Checkout(CheckoutStep { repository: CheckoutRepo::Named(alias), ... }) for each alias, mirroring lines 848–862 of the Agent job builder. Use front_matter.checkout_fetch.get(alias) for per-repo fetch opts.

  // inside `if variant.runs_create_pull_request { ... }`
  for repo in &front_matter.checkout {
      let fetch = front_matter.checkout_fetch.get(repo).cloned().unwrap_or_default();
      steps.push(Step::Checkout(CheckoutStep {
          repository: CheckoutRepo::Named(repo.clone()),
          clean: None,
          submodules: None,
          fetch_depth: fetch.depth_for_emit(),
          fetch_tags: fetch.fetch_tags,
          persist_credentials: None,
      }));
  }

  Place this before the install_and_download_steps_typed call so checkout layout is established before prepare-pr-base.js runs.

• 2. Extend compiler tests (tests/compiler_tests.rs)

  Extend or add assertions alongside test_create_pull_request_safeoutputs_prepare_step_covers_all_checkout_repos (line 8900):

  a. Assert checkout: tools and checkout: docs are present in the SafeOutputs YAML before the prepare-pr-base invocation.
  b. Assert a checkout: false repo is not present (add a repo declared with checkout: false to the fixture).
  c. Assert the executor --source path uses the multi-checkout form $(Build.SourcesDirectory)/$(Build.Repository.Name)/....
  d. Assert split-approval: additional checkouts appear only in SafeOutputs_Reviewed, not in the auto SafeOutputs job.

• 3. Add executor e2e multi-repo scenario (scripts/ado-script/src/executor-e2e/scenarios/create-pull-request.ts)

  Add a createPullRequestMultiRepo scenario that:

  • Uses a second ADO repository (configurable via env, e.g. EXECUTOR_E2E_SECOND_REPO) as the PR target
  • Clones both repos into separate directories under sourcesDir
  • Passes BUILD_SOURCESDIRECTORY set to the parent, with repo dirs at <sourcesDir>/<repo> and <sourcesDir>/<secondRepo>
  • Creates a patch in the second repo's checkout
  • Runs the executor with repository: <secondRepoAlias> and asserts the PR lands in the second repo

  Export it in the createPullRequestScenarios array and register it in scripts/ado-script/src/executor-e2e/scenarios/index.ts.

• 4. Guard e2e scenario when second repo unavailable

  If EXECUTOR_E2E_SECOND_REPO is unset, skip or mark the multi-repo scenario as optional: true (matching the pattern used by targetsAdoRepo scenarios) so CI environments that only have a single repo don't hard-fail.

---

Validation Strategy

1. cargo test — existing test_create_pull_request_* tests must pass; new checkout-step assertions must pass.
2. cargo test --test bash_lint_tests — no new shellcheck issues from the additional checkout steps.
3. Executor e2e pipeline (the ADO smoke) should exercise the new createPullRequestMultiRepo scenario end-to-end once a suitable second repo is configured.

---

Risks and Mitigations

Risk	Mitigation
Additional checkout steps may cause credential or permission issues for the SafeOutputs build identity	The existing checkout: self already uses the build identity; named repos in repos: are declared as resources and ADO will apply the same token. No change to auth surface.
Placing the extra checkouts inside if variant.runs_create_pull_request means a checkout: false repo is silently absent — patch is correct but subtle	Explicit test assertion (#2b above) guards this
Second ADO repo for executor e2e may not always be available	Guard on env var; make scenario optional

---

Dependencies and Assumptions

• front_matter.checkout already only contains repos with checkout: true (filtered by resolve_repos in common.rs, line 1510), so no additional filter is needed.
• The executor e2e multi-repo scenario requires a second accessible ADO Git repository in the same project; pipeline configuration needed to pass the repo name.
• Split-approval logic (SafeOutputsVariant::automatic / reviewed) controls runs_create_pull_request per variant — the fix correctly scopes additional checkouts to the right variant without any structural changes to SafeOutputsVariant.

Generated by Issue Plan Maker for #1731 · 41 AIC · ⌖ 6.15 AIC · ⊞ 6K · ◷
_{Comment /plan to run again}