ci(pipeline): add package build to Control Tower integration#17116
Open
dmcilvaney wants to merge 3 commits intomicrosoft:tomls/base/mainfrom
Open
ci(pipeline): add package build to Control Tower integration#17116dmcilvaney wants to merge 3 commits intomicrosoft:tomls/base/mainfrom
dmcilvaney wants to merge 3 commits intomicrosoft:tomls/base/mainfrom
Conversation
Add a 'Submit package build to Control Tower' step that calls the
/api/Scenario/package endpoint after the prcheck step succeeds. The
step is gated on PR triggers so unmerged code never kicks off a build.
Naming: the pipeline now does more than source upload, so rename to
reflect what it actually does (call Control Tower).
* sources-upload.yml -> control-tower-integration.yml
* sources-upload-stages.yml -> control-tower-integration-stages.yml
* Stage PRCheck -> Integration
* Job CallControlTowerAPI -> UploadAndBuild
Both API calls live in a single job. Two jobs would have doubled the
fixed-cost OneBranch SDL/binary-analysis injections, required a
cross-job artifact handoff for the changed-components JSON, and bought
us only marginal isolation -- upload finishes in minutes and the
package-build call only briefly polls to confirm acceptance.
The ADO pipeline definition's 'YAML file path' must be updated in the
portal from sources-upload.yml to control-tower-integration.yml when
this lands.
Package-build step details:
* condition: and(succeeded(), ne(Build.Reason, PullRequest))
* Reuses the changed-components JSON from earlier in the job, filters
to changeType in {added, changed}, submits with packageTarget=azl4,
isScratchBuild=true.
* run_package_build.py polls briefly (default 5 min) just to confirm
the job left Queued; full build progress is monitored in CT itself.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a Control Tower “package build” submission to the existing Control Tower integration ADO pipeline so that, after the prcheck/upload portion completes successfully, the pipeline can also request package builds for changed components (while still gating builds off PR-triggered runs).
Changes:
- Introduces
run_package_build.pyto submit/api/Scenario/packagerequests and briefly poll for early failure/acceptance. - Extends the raw ADO stages template to run the new “Submit package build to Control Tower” step on non-PR triggers only.
- Renames/aligns pipeline naming and documentation to reflect broader “Control Tower integration” responsibilities.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/scripts/control-tower/run_package_build.py | New helper script to submit package-build scenarios and do a short acceptance/health poll. |
| .github/workflows/ado/templates/control-tower-integration-stages.yml | Adds a new AzureCLI step to submit package builds after prcheck on non-PR triggers; renames stage/job. |
| .github/workflows/ado/control-tower-integration.yml | Updates wrapper comments and points the wrapper to the renamed stages template. |
| .github/instructions/ado-pipeline.instructions.md | Updates examples/canonical references to use the new Control Tower integration pipeline names. |
reubeno
reviewed
May 11, 2026
Member
reubeno
left a comment
reubeno
left a comment
There was a problem hiding this comment.
Why did we end up with "package build" as the contract between CI and Control Tower? I understand that we've made the call to detect changes on the workflow/pipeline side -- but my expectation is still that the Control Tower will decide which tasks need to be run, depending on whether it's pre-merge qualification, or as part of merge/post-merge.
Did we not add endpoints to Control Tower that are more scenario driven?
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
NOTE: This will require changes on the ADO side to align with the new names.
Add a 'Submit package build to Control Tower' step that calls the /api/Scenario/package endpoint after the prcheck step succeeds. The step is gated on PR triggers so unmerged code never kicks off a build.
Naming: the pipeline now does more than source upload, so rename to reflect what it actually does (call Control Tower).
Both API calls live in a single job. Two jobs would have doubled the fixed-cost OneBranch SDL/binary-analysis injections, required a cross-job artifact handoff for the changed-components JSON, and bought us only marginal isolation -- upload finishes in minutes and the package-build call only briefly polls to confirm acceptance.
The ADO pipeline definition's 'YAML file path' must be updated in the portal from sources-upload.yml to control-tower-integration.yml when this lands.
Package-build step details: