Update CFS and other OneBranch tooling#1422
Conversation
|
Watching the OneBranch run, it failed on Windows only at the signing step due to the internal service timing out, so I think this is at least good to go for review. Edit: found the reason for that, and for the previously added |
|
Last thing is symbols and uh, fixing the path highlighted that this wasn't working in the first place. Went back and looked at a "successful" build... Linux
macOS -- N/A Windows
|
|
Assigning reviewers now as that's a green build. I still don't think the Windows symbols are source mapped but that's a different investigation. |
|
By the way this is a follow-up to #1410 as I needed the OneBranch pipeline to work again so I could get the MSIX, RPM, and DEB packages and verify them. |
|
Nope, one more thing to fix. MSIX bundle is getting created under |
|
Bingo, MSIX bundle now exists too. |
There was a problem hiding this comment.
Pull request overview
Updates the repo’s build/packaging and OneBranch pipeline configuration to use a pinned msrustup toolchain and a new Azure Artifacts Cargo mirror, simplifying authentication and fixing MSIX packaging behavior.
Changes:
- Pin Rust toolchain to
ms-prod-1.93across scripts and OneBranchRustInstallerusage. - Switch Cargo source replacement to the
DSCCargoMirrorfeed and useCargoAuthenticate@0in pipelines (removing Azure CLI token plumbing / restore-phase workarounds). - Pass through
-UseX64MakeAppxfor MSIX builds and adjust MSIX bundle output pathing; includedsc-bicep-extin the RPM file list.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| packaging/rpm/dsc.spec | Adds /usr/bin/dsc-bicep-ext to the RPM %files list to match the installed symlink. |
| packaging.ps1 | Removes -UseCFSAuth flow and pins msrustup channel to ms-prod-1.93. |
| helpers.build.psm1 | Pins msrustup channel, adds -UseX64MakeAppx plumbing for MSIX, and adjusts MSIX bundle output location. |
| build.ps1 | Removes -UseCFSAuth usage and passes UseX64MakeAppx through to packaging. |
| .pipelines/DSC-Windows.yml | Uses ms-prod-1.93 and CargoAuthenticate, removes token parameter and restore-phase/task ordering workarounds, and updates paths. |
| .pipelines/DSC-Official.yml | Updates official pipeline jobs to use CargoAuthenticate and pinned toolchain; removes AzureCLI token acquisition and related variables. |
| .github/instructions/instructions.md | Removes -UseCFSAuth from documented build parameters. |
| .cargo/config.toml | Switches crates.io replacement to the DSCCargoMirror feed. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| $buildParams = @{ | ||
| BuildData = $BuildData | ||
| ArtifactDirectory = $artifactDirectory | ||
| Architecture = $Architecture | ||
| Release = $Release | ||
| UseX64MakeAppx = $UseX64MakeAppx | ||
| } |
There was a problem hiding this comment.
Build-DscPackage now adds UseX64MakeAppx into the splatted @buildParams hashtable, but Build-DscZipPackage and Build-DscTgzPackage don't accept that parameter. This will throw a runtime error when packaging zip or tgz. Consider only adding UseX64MakeAppx to the parameter set when calling Build-DscMsixPackage, or filter/remove the key before splatting into the other packaging functions.
There was a problem hiding this comment.
@andyleejordan since this param is only used for MSIX, yo ucould just move it to line 2180
The crux of our problems was the cross-org feed permissions.
The version ms-stable stopped being supported in 2024 so we've been on an old toolchain.
Which removes the need to do complicated authentication.
The OneBranch template automatically checks out the repo, doing it again is what messed up CodeQL and signing.
It never worked on Linux in the first place, so disable that. On Windows it needs to be where we built, not where we're packaging the MSIX (and so have lost our sources and symbols).
We were assuming this was bin root (like in the old package script).
And update PSDesiredStateConfiguration to 2.0.8. This feed is already dedicated to mirroring the PSGallery. Importantly, it does not have NuGet.org as an upstream since doing so can cause package name conflicts. While it is cross-org, we are not depending on automated write-access and it is purposely publicly-readable.
| $buildParams = @{ | ||
| BuildData = $BuildData | ||
| ArtifactDirectory = $artifactDirectory | ||
| Architecture = $Architecture | ||
| Release = $Release | ||
| UseX64MakeAppx = $UseX64MakeAppx | ||
| } |
There was a problem hiding this comment.
@andyleejordan since this param is only used for MSIX, yo ucould just move it to line 2180
|
@SteveL-MSFT that change is applied, it's low risk but I'll still kick off a pipeline to test as that's the only way to verify it. Also opened #1425 |
In the course of debugging why we couldn't so much as
cargo install tree-sitter-cliI discovered a number of issues resolved in this PR.For the
msrustuptoolchain,ms-stablestopped being supported in 2024, meaning under the covers we've just been usingms-prod-1.88. I've updated the OneBranch pipelines to specifically usems-prod-1.93. The OneBranch documentation recommends a specific pin, and not e.g.ms-prod. They also recommend using arust-toolchain.tomlfile, but that gets a bit in the way of our existing logic which detects and usesmsrustuponly when available.I've switched us from the mscodehub CFS feed to a new dedicated
DSCCargoMirrorCFS feed in msazure. By not being cross-org, we don't have to deal with complicated authentication with a service connection, and can just rely on theCargoAuthenticatetask. I know of no compelling reason to stick to the mscodehub feed when we can eliminate a lot of headache here.If and when as a dev you cannot update the feed, there is a very hidden button titled "Allow externally-sourced versions" available only after going to the feed and searching the upstream sources for a package. I've found it sometimes just gets turned off, which then prevents us from adding packages to the feed, and this will appear as an authentication failure. Authenticating locally with either
artifacts-cargo-credproviderormsrustupdoes indeed work, but that setting must be toggled on.I removed
ob_restore_phase: trueas that was an old workaround for accessing network resources that were not allow-listed, and it messed up the timing of the tasks. Seems like it was put there because we were errantly adding a secondcheckout: selftask (it's an additional since the OneBranch template already does that). With that gone, ordering is fine and signing and CodeQL is happy.We also weren't passing through
-UseX64MakeAppxwhen we migrated the MSIX build function, and that needs to happen for one of the OneBranch builds.