chore(ci): retry the package lock bump until npm resolves

[ShaneK]

Issue number: internal

---

What is the current behavior?

Currently, the update-package-lock job fails the release with ETARGET No matching version found for @ionic/core@^9.0.x. Since 9.0.4 npm processes publishes asynchronously, so npm publish returns before the version resolves. The registry recorded @ionic/core 4s after the publish step on 9.0.3, but 5m11s on 9.0.4 and 5m10s on 9.0.5, against a near constant 5m04s gap from publishing to that job, so the last two releases each missed by about six seconds and needed the job re-run by hand.

Separately, purge-cdn-cache has never done anything. A missing comma before the @next CSS entry made the body invalid JSON, so jsDelivr rejected every purge with InvalidContent while curl exited 0 and the step stayed green. That has been true since #29121.

What is the new behavior?

The Bump Package Lock step is split into Resolve Package Locks, which retries lerna exec "npm install --package-lock-only --prefer-online" every 15s against a 900s wall clock deadline, and Commit Package Locks, which does the commit and the push. We retry the install rather than probing with npm view first, because the two read separately cached documents and a passing probe wouldn't mean the install resolves. The --prefer-online flag is required because a failed install caches the version-less packument locally for 300s, so plain retries never reach the registry. The bound is wall clock rather than an attempt count since one attempt costs about 45s and a fixed count would overrun timeout-minutes.

The purge-cdn-cache job now runs after update-package-lock and gates on a new resolved output rather than the job's result, so a failed lockfile push still purges but an unresolved version doesn't. The comma is fixed and the step checks the HTTP status, failing on a 4xx because a bad payload is otherwise silent, and warning on anything else so a jsDelivr outage doesn't fail a release.

Does this introduce a breaking change?

• Yes
• No

Other information

The release.yml workflow only runs on a real production release, so I couldn't test this end to end. I ran each step's shell against stubs for the failure paths, but the first real signal will be the next release.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ionic-framework	Ready	Preview	Sep 23, 2026 8:24pm UTC