Publish the mxc-sdk crate closure to crates.io

[Darren Hoehna (dhoehna)]

What this does

Adds a dedicated pipeline that packages the mxc-sdk crate closure — 20 crates — and publishes them to crates.io through ESRP Release, one crate at a time in leaf-first order. Publishing is manual and gated on a release ref, so nothing reaches crates.io until a release is deliberately cut.

Running a release

The pipeline is MXC-Release-Crates, definition 198954: https://microsoft.visualstudio.com/Dart/_build?definitionId=198954

Push a release ref to microsoft/mxc and pick it in the Run dialog's branch/tag selector. Validate_Release_Ref accepts exactly two shapes and fails the run on anything else:

• a release branch, refs/heads/release/* — for example release/v0.8.0
• a version tag, refs/tags/v* — for example v0.8.0

The gate carries isSkippable: false, so it cannot be switched off in the "Stages to run" panel, and both Package_Crates_For_Release and Publish_to_CratesIo depend on it. The definition carries no triggers, so a pipeline that publishes to a public registry cannot fire on a push.

Two things worth knowing before the first run. The ref must exist on microsoft/mxc — the Run dialog enumerates that repository only, so a branch pushed to a fork will not appear. And a release branch is not immutable on its own: the gate proves where a run came from, not that the ref cannot move. Freeze it with a GitHub ruleset (Settings → Rules → Rulesets) blocking pushes, force-pushes, and deletion, or use a tag.

dryRun defaults to true: it packages the closure and checks the publish order, then skips the publish stage entirely — the run reports that stage as Skipped rather than green, so a rehearsal is distinguishable from a publish at a glance. Set it to false to publish for real. It is the only field in the Run dialog. The ESRP owner and approver are not fields: ADO renders every top-level parameters: entry as an editable box, and an email is not a decision the person clicking Run should make — there is no right answer for them to know, and a typo submits the release to the wrong owner. Both are fixed in the YAML to $(Build.RequestedForEmail), which is what a default run already used, so this removed the prompt and not the behavior. A runtime guard in the gate stage fails the run if that variable resolves empty, which it can for a run queued by a service identity rather than a person.

The pipeline needs no crates.io network access: the 1ES pool's CFSClean isolation blocks crates.io, dependency resolution stays on the private Mxc-Azure-Feed, and ESRP owns the publishing credentials. Operator steps are documented in docs/crates-release.md.

How it works

• Packaging is a single cargo package run with one -p flag per crate against --registry Mxc-Azure-Feed. That override works around A bug about cargo publish --workspace --registry crates-io rust-lang/cargo#17196, under which just-packaged workspace siblings are otherwise looked up in the wrong source and not found. Cargo's verification build stays on, so a mismatched sibling version requirement fails packaging.
• The whole pipeline runs on Windows, and every crate is verified for all three platforms we ship. That same cargo package call carries three --target flags — x86_64-pc-windows-msvc, x86_64-unknown-linux-gnu, and aarch64-apple-darwin — which cargo honors together and builds in parallel. A crate that no longer compiles on Linux or macOS therefore fails at package time, before anything is published, instead of after. The publish stage depends on that job, so any red triple stops the release. Verifying on Windows costs nothing in fidelity: the .crate tarball is written before the verification build starts, and independent Windows and Linux runs produce a byte-identical archive, so the artifacts published from the Windows agent are the same bytes either way. The three triples are installed by the job; crates_release.py independently confirms each one is present and fails the run if it is not, so a missing target can never quietly reduce what was checked.
• The publish order is computed, not maintained. CRATES in crates_release.py is an unordered set of package names; the order is a leaf-first topological sort of the workspace dependency graph derived from cargo metadata, with alphabetical tie-breaking. Packaging derives it live; the template's crateOrder is a pasted copy of the same computation, because ${{ each }} expands before any script runs. A pasted copy can drift, and drifting failed silently: verify-order accepts an ordered subset on purpose, since that is how a part-published release resumes, so a template missing a newly-added crate passed and the crate was simply never published. check-template now recomputes the order on every PR and fails the build unless the template matches exactly. Adding a crate is: add the name, run crates_release.py order, paste the output — and CI fails if you forget the last step.
• The order and a per-crate SHA-256 are recorded in release-order.json. Each staged .crate is re-checked against that digest before ESRP submission, and staging fails closed if the digest is missing or disagrees. verify-order accepts an ordered subset of the packaged closure, which is what makes resuming a partly-published release possible.
• The official build gains an opt-in packageCrates parameter (default false) that runs the same packaging as a merge-time canary; it produces the artifact but never publishes.
• src/Cargo.toml sets repository under [workspace.package] and pins version = "0.7.0" on the first-party path dependencies so they are publishable.

Validation

• ADO preview compile of 1ES.Release.Crates.yml against definition 198954 — HTTP 200, expanding to the three stages and 20 EsrpRelease@12 tasks.
• Ref gate exercised against 10 real refs — accepts release/* branches and v* tags, rejects main, user/*, bare commits, and the case variants Release/x and V1. The gate uses PowerShell -clike rather than -like, because -like is case-insensitive and would admit refs the release/* ruleset does not freeze.
• verify-order exercised against the generated order — accepts the full 20-crate list and an 8-crate resume subset, rejects an out-of-order pair and an unknown crate name.
• cargo package across all 20 crates in a single invocation against all three target triples, on a clean tree — exit 0, 20 .crate files produced, and per-triple .rlib artifacts present for 20 of 20 crates under x86_64-pc-windows-msvc, x86_64-unknown-linux-gnu, and aarch64-apple-darwin. Sixty of sixty cells built. Twelve of those cells are deliberately near-empty libraries, per the Windows-only note above; the check is that the closure compiles on every platform, not that every crate carries code on every platform.

Still open

• The pipeline is not yet authorized on the Azure-Pipelines-1ESPT-ExDShared agent pool — resolved. Runs 154036650 and 154039902 both allocated agents on queue 250521 and executed. The MXC-ESRP-Signing variable group and the MXC-ESRP-Auth service connection are both authorized.
• hyperlight_common cannot publish under that name. It normalizes to hyperlight-common, already taken on crates.io by hyperlight-dev (v0.16.0), and crates.io treats - and _ as equivalent. A broader mxc_ prefix policy for the whole closure is under discussion, and would supersede a single rename.
• ESRP Rust content-type enablement for the MXC client ID, OSPO open-source release registration, and a crates.io PublishNew rate-limit override all remain to be requested. ESRP does support Rust and crates.io publishing; what is missing is per-client-ID enablement.
• cargo package --verify fails on the Linux agent. — resolved, and the original diagnosis was incomplete. Run 154039902 packaged all 20 crates and then failed verifying isolation_session_bindings, because Package.Crates.Job.yml pinned ubuntu-latest while four crates in the closure are Windows-only. There were two independent causes, not one. Ungated windows-rs dependencies in isolation_session_bindings and wslc_common were the first; the crate that actually breaks is windows-future 0.3.2, which references windows_threading::submit and windows_core::imp::IMarshal unconditionally while both sit behind a crate-wide cfg(windows) — rust-lang/windows-rs#4738, whose fix is unreleased, so gating our own manifests is the only remedy. The second was windows_sandbox_common reaching base64 helpers through wxc_common::string_util, a Windows-gated module, when the helpers are portable and already live in the ungated wxc_common::encoding. Verifying macOS then surfaced two more that no pipeline had ever covered: nanvix_common gated its constants to Linux specifically rather than to non-Windows, and nanvix_runner calls a module that exists only on Windows and Linux. Moving to Windows was necessary but not sufficient; --no-verify was refused throughout, since it would delete the only compile check standing before an irreversible publish.
• What "verified on three platforms" does and does not mean. Four crates in the closure are Windows-only by design, and gating them does not give them Linux or macOS functionality — it makes them compile to an empty library there instead of failing the build. isolation_session_bindings, isolation_session_common, and appcontainer_common expose nothing off Windows, and nanvix_runner exposes nothing on macOS: its cfg deliberately mirrors the pre-existing gate on wxc_common::microvm_staging, which its core logic depends on and which does not exist there, so it propagates an existing platform constraint rather than inventing one. That is the correct shape for crates.io, where a package must resolve on every platform even when it does nothing there, and it is what the verification proves: the closure builds everywhere, not that every crate is useful everywhere. mxc_telemetry is partially gated the same way, which predates this change.
• No ESRP crates.io publish has ever run, so that destination is unproven. A dryRun: true run stops after packaging — it deliberately does not execute the publish job, so artifact download, verify-order, staging, and ESRP submission are all still unexercised.

[Copilot]

Pull request overview

Adds opt-in packaging and ESRP publication of the mxc-sdk crate dependency closure to crates.io.

Changes:

• Adds publishable metadata and versioned internal dependencies for 18 crates.
• Adds packaging, dependency-order validation, checksum verification, and retry-safe publishing.
• Keeps crate packaging disabled pending Cargo #17196 resolution.

Reviewed changes

Copilot reviewed 24 out of 25 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/Cargo.toml	Adds repository metadata and dependency versions.
src/mxc_telemetry/Cargo.toml	Adds repository metadata.
src/core/wxc_common/Cargo.toml	Adds package metadata and NanVix version.
src/core/mxc-sdk/Cargo.toml	Adds repository metadata.
src/core/mxc_pty/Cargo.toml	Adds publishable metadata.
src/core/mxc_engine/Cargo.toml	Adds repository metadata.
src/core/generated/base_container_specification/Cargo.toml	Makes generated bindings publishable.
src/backends/wslc/common/Cargo.toml	Adds publishable metadata.
src/backends/windows_sandbox/lifecycle/Cargo.toml	Adds license and package metadata.
src/backends/windows_sandbox/common/Cargo.toml	Adds publishable metadata.
src/backends/seatbelt/common/Cargo.toml	Adds publishable metadata.
src/backends/nanvix/runner/Cargo.toml	Adds metadata and dependency version.
src/backends/nanvix/common/Cargo.toml	Adds repository metadata.
src/backends/lxc/common/Cargo.toml	Adds publishable metadata.
src/backends/isolation_session/common/Cargo.toml	Adds publishable metadata.
src/backends/isolation_session/bindings/Cargo.toml	Makes bindings publishable.
src/backends/hyperlight/common/Cargo.toml	Adds publishable metadata.
src/backends/bubblewrap/common/Cargo.toml	Adds publishable metadata.
src/backends/appcontainer/common/Cargo.toml	Adds publishable metadata.
.azure-pipelines/templates/Publish.CratesIo.Job.yml	Defines ordered ESRP publication workflow.
.azure-pipelines/templates/Package.Crates.Job.yml	Packages the crate closure as an artifact.
.azure-pipelines/templates/1ES.Build.Stages.yml	Adds the opt-in packaging stage.
.azure-pipelines/scripts/crates_release.py	Validates, stages, and verifies crate releases.
.azure-pipelines/1ES.Release.yml	Adds selectable npm and crates.io release stages.
.azure-pipelines/1ES.Build.Official.yml	Exposes the crate-packaging parameter.

[Darren Hoehna (dhoehna)]

Good catch - this was correct and would have failed validation before any step ran.

Confirmed against the 1ES release-job docs, whose deployment-job example annotates the field as required verbatim: environment: MyEnvironment # Required, name of the environment.

Fixed in d408846 by taking your second suggestion: converted to a standard job with templateContext.type: releaseJob and flattened strategy.runOnce.deploy.steps into plain steps:. That matches the NPM release job already working in 1ES.Release.yml, and it avoids provisioning an ADO Environment (and the approval gates that come with it) purely to satisfy the schema. The 1ES docs show the standard-job form for release jobs in four of their five examples, so it is the better-trodden path here.

[Copilot]

Pull request overview

Copilot reviewed 24 out of 25 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

.azure-pipelines/templates/Publish.CratesIo.Job.yml:27

• The PR description promises automatic crates.io checksum/existence checks and checksum-aware reruns, but this implementation explicitly performs no registry reads and requires operators to remove crates manually. That means a resumed run can publish dependents based only on an unchecked operator assertion, and an unchanged rerun is not safe as described. Either restore the advertised preflight/ledger behavior in a network-capable stage or update the release design and PR description to make this manual safety boundary explicit.

# RESUMING A FAILED RELEASE: crates.io rejects a duplicate version, so simply
# re-running this job unchanged fails on the first crate that already landed.
# The pool cannot ask crates.io what landed, and 1ES forbids `checkout` in a
# release job, so there is no automated ledger. Instead the operator re-queues
# the release with the already-published crates removed from `crateOrder`.
# `verify-order` accepts that subset only if it is still in packaged leaf-first
# order, and logs every dependency it is consequently assuming is already live.

.azure-pipelines/scripts/crates_release.py:229

• This disables Cargo's only check that each generated archive can compile after workspace path dependencies are rewritten to registry dependencies. A successful workspace build does not cover missing packaged files or normalized-manifest problems, so the release can publish crates that consumers cannot build. Remove --no-verify (the private-registry workaround should also support verification), or add an equivalent build-from-archive gate before this stage is enabled.

        "--no-verify",

[Darren Hoehna (dhoehna)]

Two outstanding items that need a decision

Both are external to this PR - no amount of code review resolves them, and both have lead time, so they are worth starting now rather than at release time.

1. hyperlight_common name collision on crates.io

hyperlight_common normalizes to hyperlight-common, which is already taken on crates.io by the hyperlight-dev project (currently v0.16.0, actively maintained). crates.io treats - and _ as equivalent for uniqueness, so neither spelling is available to us. Re-verified 2026-08-03; the other 17 names in the closure are free.

This is a hard stop for that one crate - it is not a "retry later" situation, and it will not free up on its own.

Options:

1. Rename before first publish (e.g. mxc_hyperlight_common). Cheapest and fully under our control, but it becomes a permanent public name.
2. Request co-ownership or a transfer from hyperlight-dev. Possibly viable given the shared Microsoft context, but it is a negotiation with unknown latency.
3. Exclude it from the published closure - only viable if nothing else we publish depends on it, which needs checking.

This is a naming/ownership call rather than an engineering one. Gudge (@MGudgin) - flagging for you and Anis; I am sending you both the details separately by email.

2. crates.io publish rate limit for 18 new crates

Publishing a new crate is rate-limited separately from publishing a new version of an existing one. Per the crates.io source defaults, the new-crate bucket is a burst of 5 with a refill of 1 per 10 minutes, so an 18-crate first release stalls at crate #6 and then trickles - roughly two hours of pure waiting.

Caveat worth stating: those are the defaults in the crates.io source. I have not been able to confirm the values actually configured in production, so treat the two-hour figure as an estimate rather than a measurement.

This only affects the first release; subsequent version bumps use the much more generous update bucket.

Options:

1. Request an override via help@crates.io. They maintain a per-publisher override table for exactly this case (bulk onboarding of a crate family). Needs lead time.
2. Accept the serial ~2h release. Workable, but it makes the first run long and therefore more likely to be interrupted - see the resume procedure in the PR description.

---

Not blocking, but worth knowing

MXC has never executed an ESRP crates.io publish - not once. Whether ESRP is onboarded for crates.io as a destination for this product is an open question for the ESRP team. The credentials themselves are proven (the same ESRPInfo bundle already drives our NPM release and Mac/Rust signing); it is specifically the crates.io destination that is unverified.

Relatedly, the packaging fix in this PR has been proven on 2-crate probes in the identical sibling shape but not against the real 18-crate closure. packageCrates deliberately stays false. I would recommend one opt-in packageCrates: true run on the official build as the next step - it validates the fix at full scale and publishes nothing.

---

Branden Bonaby (@bbonaby) - could you take a look? The parts most worth your attention are the deletion of the four crates.io reads in Publish.CratesIo.Job.yml and the three-layer safety argument in the PR description that justifies it, since that is where I would most want a second opinion on whether anything is actually lost.

[Copilot]

Pull request overview

Copilot reviewed 24 out of 25 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.azure-pipelines/templates/Publish.CratesIo.Job.yml:94

• The release starts the next dependent crate immediately after ESRP reports completion, but crates.io index updates are asynchronous; the new dependency may not yet be resolvable, causing the next publish to fail with “dependency does not exist.” The PR’s Safety section says propagation is awaited, but this loop has no delay or retry. Add a supported propagation gate after each publish (preferably polling the sparse index from a network-enabled job, or a conservative wait if this pool must remain isolated).

            - task: EsrpRelease@12

.azure-pipelines/templates/Publish.CratesIo.Job.yml:30

• This explicitly contradicts the PR’s Safety claim that reruns skip versions already published with the matching checksum. The implementation instead fails on duplicates and asks an operator to remove entries without verifying the published checksum, so a partial release is neither automatically resumable nor checksum-safe as described. Restore the live checksum/idempotency check (for example in a permitted network-enabled gate or trusted publication ledger), or revise the stated release guarantees before relying on this workflow.

# RESUMING A FAILED RELEASE: crates.io rejects a duplicate version, so simply
# re-running this job unchanged fails on the first crate that already landed.
# The pool cannot ask crates.io what landed, and 1ES forbids `checkout` in a
# release job, so there is no automated ledger. Instead the operator re-queues
# the release with the already-published crates removed from `crateOrder`.

[Copilot]

Pull request overview

Copilot reviewed 24 out of 25 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 27 changed files in this pull request and generated no new comments.

Suppressed comments (2)

docs/crates-release.md:67

• The release procedure will break on the next version bump. These newly versioned path dependencies keep literal 0.7.0 requirements (including the two direct nanvix_common dependencies), so changing only [workspace.package].version makes the local 0.8.0 siblings fail the 0.7.0 requirements; scripts/check-version-sync.js does not update or validate them. The instructions must require updating every first-party dependency requirement in lockstep (and the SDK versions checked by the existing sync gate).

1. Bump the version in `src/Cargo.toml`.

.azure-pipelines/1ES.Release.Crates.yml:80

• The release entry point advertised in the PR description is not present: this new pipeline exposes cratesDryRun, while the existing 1ES.Release.yml has no publishCrates parameter or crates stages. Queueing MXC-Official-Release with publishCrates: true therefore cannot perform the documented release. Either integrate these stages into that pipeline or update the PR description to direct operators to the separately registered 1ES.Release.Crates.yml pipeline.

parameters:
  - name: cratesDryRun
    displayName: 'Dry run — package and verify order but skip ESRP publish'
    type: boolean
    default: false

[Copilot]

Pull request overview

Copilot reviewed 26 out of 27 changed files in this pull request and generated 2 comments.

Suppressed comments (2)

docs/crates-release.md:156

• This resume procedure repackages the remaining crates from a new commit rather than the original release tag/artifact. If main has advanced, Cargo verifies against the new local sibling sources while consumers resolve already-published siblings from the old tag, allowing an incompatible mixed closure under one version; even a pipeline-only commit changes Cargo's packaged VCS provenance/checksum. Resume from the original artifact/tag while supplying only the remaining order, rather than tagging a new main commit.

2. Edit the `crateOrder` default in `.azure-pipelines/1ES.Release.Crates.yml`,
   removing the already-published crates, and merge that change to `main`.
   `crateOrder` is an `object` parameter; changing it means editing the
   pipeline file.
3. Cut a **new** release tag containing that edit (for example

docs/crates-release.md:62

• This release step is incomplete now that the PR adds literal version = "0.7.0" requirements for first-party dependencies in the workspace and crate-local manifests. Changing only workspace.package.version to 0.8.0 leaves packages requiring ^0.7.0 siblings, so cargo package will reject the next release. Include those dependency requirements in the version bump instructions.

1. Bump the version in `src/Cargo.toml`.

[Copilot]

Pull request overview

Copilot reviewed 28 out of 29 changed files in this pull request and generated no new comments.

Suppressed comments (4)

docs/crates-release.md:256

• This resume procedure no longer builds from the failed run's exact commit: the crateOrder edit must be committed before the branch is pushed, and cargo package embeds that new HEAD in each archive's .cargo_vcs_info.json. The resumed crates therefore have different provenance from the first part of the release. Reuse the original package artifact, or make the verified publish subset a queue-time input while running the original immutable ref.

3. On that branch, edit the `crateOrder` default in
   `.azure-pipelines/templates/Publish.CratesIo.Job.yml`, removing the
   already-published crates. Keep the remaining entries in their existing
   relative order, and **do not** rerun `crates_release.py order` — that
   regenerates the full closure and would put the already-published crates

docs/crates-release.md:174

• These defaults contradict both the pipeline definition and the ESRP identity section below: the parameters default to $(Build.RequestedForEmail), not this individual address. This would give operators incorrect instructions about which identity is submitted.

   | **ESRP release owners email** (`esrpOwnersEmail`) | Defaults to `Darren.Hoehna@microsoft.com`; see [ESRP identity](#esrp-identity) below. |
   | **ESRP release approvers email** (`esrpApproversEmail`) | Defaults to `Darren.Hoehna@microsoft.com`; see [ESRP identity](#esrp-identity) below. |

docs/crates-release.md:321

• This prerequisite is stale relative to the PR description: definition 198954 is already registered, and the variable group and service connection are authorized. The unresolved authorization is for the Azure-Pipelines-1ESPT-ExDShared agent pool (queue 250521), so the current runbook directs operators to fix the wrong resource.

5. **Pipeline registration** — `.azure-pipelines/1ES.Release.Crates.yml` is new
   and must be registered as a pipeline in Azure DevOps, and that pipeline must
   be authorized to use the `MXC-ESRP-Signing` variable group.

.azure-pipelines/templates/1ES.Build.Stages.yml:100

• This comment incorrectly says the official-build artifact is consumed by the release pipeline. 1ES.Release.Crates.yml packages its own ref and consumes only the artifact from that same run; this stage is an independent canary. Keeping the distinction explicit avoids accidentally coupling release operations to the wrong build artifact.

    # Source-only (no binaries), so it does not depend on Build_Binaries. Produces
    # the `mxc-crates-package` artifact consumed by 1ES.Release.Crates.yml for ESRP-based
    # crates.io publishing. Isolated in its own stage so it never gates npm
    # packaging or the integration tests that depend on Package_MXC.

[Copilot]

Pull request overview

Copilot reviewed 29 out of 30 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/Cargo.toml:113

• These hard-coded local dependency requirements become additional version sources, but the existing version-sync check only compares the workspace, npm, and C# package versions. Following the new release guide's instruction to bump src/Cargo.toml to 0.8.0 leaves these requirements at ^0.7.0, so workspace resolution/cargo package fails before that documented release can run. Add a CI check that keeps every publishable path dependency requirement synchronized with the workspace version, and include those pins in the version-bump procedure.

wxc_common = { path = "core/wxc_common", version = "0.7.0" }
mxc_engine = { path = "core/mxc_engine", version = "0.7.0" }
mxc-sdk = { path = "core/mxc-sdk" }
appcontainer_common = { path = "backends/appcontainer/common", version = "0.7.0" }
windows_sandbox_common = { path = "backends/windows_sandbox/common", version = "0.7.0" }

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[Copilot]

Pull request overview

Copilot reviewed 29 out of 30 changed files in this pull request and generated no new comments.

Suppressed comments (4)

.azure-pipelines/scripts/crates_release.py:601

• check-template accepts a RESUME-SUBSET marker in every invocation, including the GitHub versioning check. Therefore a resume branch merged into main with a shortened list and marker passes CI, contrary to docs/crates-release.md:304-308, and leaves future releases silently incomplete. Make resume acceptance explicit (for example, an --allow-resume-subset flag used only by the dedicated release job); the default CI check must require the full order.

    if resume_reason is not None:

src/Cargo.toml:110

• These literal first-party requirements add new version-bump targets, but the established process says to update only the workspace/npm/C# versions and the sync check validates only those (.github/copilot-instructions.md:235, scripts/check-version-sync.js:15-57). For the documented 0.8.0 release, these ^0.7.0 requirements no longer match the 0.8.0 sibling crates, so cargo package fails. Extend the version-sync check and update the release/contributor guidance to keep all first-party requirements aligned.

wxc_common = { path = "core/wxc_common", version = "0.7.0" }
mxc_engine = { path = "core/mxc_engine", version = "0.7.0" }

.azure-pipelines/templates/Publish.CratesIo.Job.yml:146

• The real-publish branch is currently enabled even though this PR documents two guaranteed mid-release blockers: the unraised first-publish rate limit and the hyperlight_common name collision. Setting dryRun=false can permanently publish the early crates and then fail, leaving an avoidable partial release. Hard-disable or gate this branch until those blockers are resolved, rather than relying only on operator instructions.

          - ${{ else }}:
            - task: EsrpRelease@12

docs/crates-release.md:384

• This prerequisite is stale relative to the PR description: MXC-Release-Crates is already registered as definition 198954 and the signing variable group is authorized. The unresolved prerequisite is authorization on the Azure-Pipelines-1ESPT-ExDShared agent pool, so the operator runbook currently directs readers to the wrong setup action.

5. **Pipeline registration** — `.azure-pipelines/1ES.Release.Crates.yml` is new
   and must be registered as a pipeline in Azure DevOps, and that pipeline must
   be authorized to use the `MXC-ESRP-Signing` variable group.

[Copilot]

Pull request overview

Copilot reviewed 29 out of 30 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/Cargo.toml:110

• These registry requirements create additional version sources that the documented release bump does not update. After changing [workspace.package] to the documented next version (0.8.0), these ^0.7.0 requirements (and the two direct nanvix_common requirements) reject the newly packaged 0.8.0 siblings, so cargo package cannot produce the release. Please extend the version-bump tooling/check to update and validate every first-party requirement, and update the release instructions and Copilot versioning convention accordingly.

wxc_common = { path = "core/wxc_common", version = "0.7.0" }
mxc_engine = { path = "core/mxc_engine", version = "0.7.0" }

.azure-pipelines/scripts/crates_release.py:601

• This success path also runs in the GitHub Versioning Checks workflow, so a PR that carries a short list plus RESUME-SUBSET returns 0 and can merge to main. That contradicts the documented backstop that main must reject resume subsets. Require an explicit --allow-resume-subset (or equivalent) only from the release-ref packaging call, while keeping the CI invocation strict.

    if resume_reason is not None:

docs/crates-release.md:388

• The known-blocker list omits the currently unresolved agent-pool authorization from the PR description. Until definition 198954 is authorized for Azure-Pipelines-1ESPT-ExDShared (queue 250521), even a dry run cannot acquire an agent; include that authorization alongside the variable group/service connection prerequisites.

5. **Pipeline registration** — `.azure-pipelines/1ES.Release.Crates.yml` is new
   and must be registered as a pipeline in Azure DevOps, and that pipeline must
   be authorized to use the `MXC-ESRP-Signing` variable group.

[Copilot]

Pull request overview

Copilot reviewed 29 out of 30 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/crates-release.md:109

• The release procedure is incomplete for the next minor version. The new first-party path dependencies carry literal version = "0.7.0" requirements (for example src/Cargo.toml:109-133), so bumping only [workspace.package].version to 0.8.0 makes those requirements reject the local 0.8.0 crates and cargo metadata/cargo package fails. Document updating all first-party dependency requirements as part of this step (and preferably provide a sync command), otherwise the documented release cannot be performed.

1. Bump the version in `src/Cargo.toml`.

[Branden Bonaby (bbonaby)]

question: I'm not sure I understand why we need the release ref thing? For every release I've done so far I've just created a tag in github https://github.com/microsoft/mxc/tags, then used that here

So I'm a bit confused why we'd need this release ref.

In terms of using the MXC-Official-Build I assumed you can use that as well just like we do with the npm release. I just kick off a new official build using the same refs/tags/ first, then I run the official release with the same refs/tags/.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.