Stabilize Azure Functions Core Tools install in CI - #19175
Draft
Adam Ratzman (adamint) wants to merge 1 commit into
Draft
Stabilize Azure Functions Core Tools install in CI#19175Adam Ratzman (adamint) wants to merge 1 commit into
Adam Ratzman (adamint) wants to merge 1 commit into
Conversation
Download the pinned 4.12.1 release archive directly instead of using the npm package's floating CDN payload. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19175Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19175" |
Contributor
There was a problem hiding this comment.
Pull request overview
Pins Azure Functions Core Tools installation to a checksum-verified GitHub release, avoiding the unreliable npm/CDN path.
Changes:
- Downloads and verifies Core Tools 4.12.1.
- Adds regression coverage for the workflow installation method.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/run-tests.yml |
Installs the pinned, verified release archive. |
tests/Infrastructure.Tests/Pipelines/NpmCliPackageTests.cs |
Guards the workflow’s release-based installation. |
Review details
Tip
Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Balanced
Contributor
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
8 tasks
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.
Unblocks the shared Playground/Core Tools gate for #18602, #18626, #19032, #19077, #19125, #19128, #19129, #19130, #19131, #19133, #19134, #19146, #19147, #19152, #19154, #19157, #19158, #19176, #19177, and #19178 — 20 PRs.
Problem
The
run-tests.ymlPlayground leg currently installs Azure Functions Core Tools through npm:npm i -g azure-functions-core-tools@4 --unsafe-perm trueThat package does not carry the Linux x64
funcpayload. Its postinstall script selects a mutable CDN zip, and the current floating 4.x zip is missing:Fresh probes while preparing this PR:
So the useful change is not just retrying a transient outage. It moves CI off a CDN-selected payload and onto a versioned release artifact.
Fix
Install Core Tools
4.12.1directly from the Azure Functions Core Tools GitHub release, verify the archive hash, add the extracted directory toPATH, and printfunc --version.The release asset is:
The workflow verifies:
This matches the existing VS Code extension E2E install shape: direct GitHub release archive + checksum +
func --version.Why not just pin npm to
azure-functions-core-tools@4.12.1?I checked the smaller one-token fix because #18626 briefly carried it. It works today, but it is deferred rather than durable.
Same-session Linux x64 proof:
But the npm pin still uses the same CDN class of URL:
Probe results:
That means
@4.12.1only works while the older CDN object happens to stay present. If that object is removed, the pin fails the same way the floating install fails now. The release-archive path is still external, but it is a versioned artifact with checksum verification, and it is already used elsewhere in the repo.Install-site audit
I searched
.github/andeng/for Core Tools installs (azure-functions-core-tools,Azure.Functions.Cli,functions.azure.com,func --version). There are two install sites in that requested scope, and noeng/install:.github/workflows/run-tests.ymlnpm i -g azure-functions-core-tools@4, which dereferences the broken CDN zip.github/workflows/extension-e2e-tests.yml4.12.1+ SHA check +func --versionfalse &&intests.yml.A whole-repo grep also finds Helix setup outside
.github//eng/:tests/helix/send-to-helix-inner.proj4.0.7512forwin-x64andlinux-x64So this PR changes one install site: the only site in the audited CI workflows that still goes through the npm/CDN postinstall path.
Platform coverage
The changed
run-tests.ymlstep only executes when:The GitHub matrix maps Linux to
ubuntu-latest; a current full main run had exactly one non-skipped instance of the step:Tests / Playground / Playground (ubuntu-latest).Tests / Hosting.Azure / Hosting.Azure (ubuntu-latest)has the step present but skipped because its short name isHosting.Azure, notAzure.The failing npm postinstall requested
Azure.Functions.Cli.linux-x64.4.13.2.zip, and the local control/fixed proof ran onuname=x86_64. I found no Windows, macOS, or arm64 execution path for thisrun-tests.ymlstep.Release asset probes:
#18626 follow-up / collision
#18626 briefly reintroduced the npm
@4.12.1workaround in the samerun-tests.ymlstep. At that head (565b06ae41), the edits touched the same lines and produced a textual merge conflict with this branch, not a silent semantic merge:Current #18626 head
afefed3456has already reverted that local pin, so there is no currentrun-tests.ymldiff on #18626. If that workaround comes back, the precise instruction is:.github/workflows/run-tests.yml, remove the local linenpm i -g azure-functions-core-tools@4.12.1 --unsafe-perm truefrom theInstall Azure Functions Core Toolsstep.shell: bash,core_tools_version='4.12.1', GitHub release archive download,sha256sum --check -, andfunc --version.Landing order: land this shared azfunc fix first, then let #18626 rebase/update on top of it. That unblocks the other affected PRs and avoids carrying a browser-debugging PR-local CI workaround.
Testing / proof
Local Linux x64 control, current
mainworkflow command:Local Linux x64 fixed script from this branch:
Latest current Playground failures verified through the Actions API fail at the install step, not in tests:
This branch also adds an Infrastructure test that guards
run-tests.ymlagainst regressing back to the npm install path and requires the release URL, checksum verification, andfunc --versionprobe.