ci(pipeline): add package build to Control Tower integration#17116
Conversation
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
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?
We looked at the control tower side, and the cost there was much higher than integrating it here in the short-term. I built the azldev components to support this so it will be easy to move this logic into CT if we desire, but this was the shortest path to functionality. |
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/delta_3_package_build
branch
from
8fbf85e to
c94440f
Compare
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/delta_3_package_build
branch
from
e685095 to
8217326
Compare
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.
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/delta_3_package_build
branch
from
8217326 to
f5bae39
Compare
🔒❌ Lock files are out of dateFIX: — run this and commit the result: azldev component update -p kernel -p kernel-headersOr download the fix patch and apply it: gh run download 25773772562 -R microsoft/azurelinux -n locks-patch
git apply locks.patchChanged components (2)
|
christopherco
merged commit ff517e7
into
microsoft:tomls/base/main
📄❌ Rendered specs are out of dateFIX: — run this and commit the result: azldev component render kernel-headersOr download the fix patch and apply it: gh run download 25773772562 -R microsoft/azurelinux -n rendered-specs-patch
git apply rendered-specs.patch
Content diffs`specs/k/kernel-headers/kernel-headers.spec`--- committed/specs/k/kernel-headers/kernel-headers.spec
+++ rendered/specs/k/kernel-headers/kernel-headers.spec
@@ -151,7 +151,10 @@
%changelog
## START: Generated by rpmautospec
-* Thu Apr 30 2026 Daniel McIlvaney <damcilva@microsoft.com> - 6.18.5-1
+* Wed May 13 2026 azldev <azldev@local> - 6.18.5-1
+- Local changes (uncommitted)
+
+* Thu Apr 30 2026 Daniel McIlvaney <damcilva@microsoft.com> - 6.18.3-2
- feat: introduce deterministic commit resolution via Azure Linux lock file
* Fri Jan 02 2026 Justin M. Forbes <jforbes@fedoraproject.org> - 6.18.3-1
|
Add a "Submit package build to Control Tower" step that calls the
/api/Scenario/packageendpoint after the prcheck step succeeds.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.
Stage / job rename
The pipeline now does more than source upload, so the stage and job inside the YAML are renamed to reflect what it actually does. The file names stay the same for now -- renaming the wrapper file would require a coordinated portal update of the ADO pipeline definition's YAML path, which will happen in a follow-up PR.
PRCheck->IntegrationCallControlTowerAPI->UploadAndBuildPackage-build step details
run_package_build.pyreuses the changed-components JSON from earlier in the job, filters tochangeType in {added, changed}, and submits to/api/Scenario/package.--package-targetis a parameter of the stages template (defaults set by the wrapper, currentlyazl4).--official-buildis opt-in: omitting it submits a scratch build (isScratchBuild=true); the production wrapper passes--official-buildso production runs submit non-scratch (persisted) builds.--build-reasonis consumed by the script for a local PR-trigger skip guard (buildReasonis also forwarded in the API payload). PR triggers do not submit package builds; the skip lives in the script for parity withrun_prcheck.py.Follow-up after merge
sources-upload[.yml,-stages.yml]->control-tower-integration*and update the ADO build definition's YAML file path in the portal at the same time.continueOnError: trueonce the pipeline is stable (tracked under ADO task 19179).