Context
microsoft/apm-action v1.4.2 is now released (release notes, PR #27). It fixes microsoft/apm-action#26 — restore mode no longer overwrites tracked apm.lock.yaml / apm.yml / apm_modules/ in the caller's git workspace, which was the root cause of #901 and the CI failure originally surfaced in #889.
The floating v1 tag has been retagged to v1.4.2, so any consumer pinned to @v1 is already on the fix. Our shared workflow pins @v1.4.1 explicitly, so it needs an update to pull the fix in.
Change
In .github/workflows/shared/apm.md, bump both microsoft/apm-action references from @v1.4.1 to @v1.4.2:
- Line 49:
uses: microsoft/apm-action@v1.4.1 → @v1.4.2
- Line 77:
uses: microsoft/apm-action@v1.4.1 → @v1.4.2
That's the entire change. No other edits needed (the file currently does not carry a git checkout -- . workaround — none was ever added here).
Why pin a patch version, not @v1
We pin exact versions for supply-chain reasons (immutable refs survive a tag rewrite). Mass updates ride on Dependabot / manual bumps.
Verification
After the bump, the next agentic-workflow CI run on a PR that modifies the lockfile (the #889 scenario) should succeed without the git checkout -- . step that PR #889 had to add as a workaround.
References
Context
microsoft/apm-actionv1.4.2 is now released (release notes, PR #27). It fixes microsoft/apm-action#26 — restore mode no longer overwrites trackedapm.lock.yaml/apm.yml/apm_modules/in the caller's git workspace, which was the root cause of #901 and the CI failure originally surfaced in #889.The floating
v1tag has been retagged tov1.4.2, so any consumer pinned to@v1is already on the fix. Our shared workflow pins@v1.4.1explicitly, so it needs an update to pull the fix in.Change
In
.github/workflows/shared/apm.md, bump bothmicrosoft/apm-actionreferences from@v1.4.1to@v1.4.2:uses: microsoft/apm-action@v1.4.1→@v1.4.2uses: microsoft/apm-action@v1.4.1→@v1.4.2That's the entire change. No other edits needed (the file currently does not carry a
git checkout -- .workaround — none was ever added here).Why pin a patch version, not
@v1We pin exact versions for supply-chain reasons (immutable refs survive a tag rewrite). Mass updates ride on Dependabot / manual bumps.
Verification
After the bump, the next agentic-workflow CI run on a PR that modifies the lockfile (the #889 scenario) should succeed without the
git checkout -- .step that PR #889 had to add as a workaround.References