fix(apm): maintain ai-toolkit pin via Renovate + materialize workflow - #199
Merged
Conversation
Add a custom manager that tracks `owner/repo#vX.Y.Z` tag pins under dependencies.apm in apm.yml against github-tags. Renovate now opens a PR bumping e.g. DevSecNinja/ai-toolkit v0.1.1 -> v0.2.0, version-aware and within the existing soak/grouping rules. This is the correct bumper for exact-tag-pinned APM deps: `apm update` only re-resolves the same exact tag, so it never advances a pin. The companion apm-materialize.yml workflow runs `apm install` on the bump PR to refresh apm.lock.yaml and redeploy the primitives.
The scheduled `apm update` caller is a no-op for exact-tag-pinned deps (apm update never advances an exact pin) and additionally failed at the install step (it passed a bare `0.21.0`; the microsoft/apm release tags are `vX.Y.Z`, so the installer built a 404 URL). Replaced by Renovate (maintains the pin) + apm-materialize.yml (runs apm install on the bump PR).
On any PR that changes apm.yml, run `apm install` to materialize the pinned APM packages — re-resolving apm.lock.yaml and redeploying the primitives into the harness directories — and commit the result back to the PR branch. This completes Renovate's apm.yml tag bumps, which only edit the manifest text. - Installs the apm CLI from PyPI (apm-cli), pinned + Renovate-tracked. - Pushes via the App token so required CI re-runs on the updated PR. - Skips forks (can't push to their branches) and no-ops without apm.yml.
ubuntu-24.04 ships python3 + pip, so the extra setup-python step (with an unverified action pin) is unnecessary. Install apm-cli directly with pip.
Rewrite the APM sync onboarding to describe the actual model: Renovate maintains the apm.yml tag pin and apm-materialize.yml runs `apm install` on the bump PR. Replaces the previous scheduled `apm update` description, which is a no-op for exact-tag-pinned dependencies.
The custom-manager governance test requires every datasource a custom manager emits to have label + semanticCommitScope rules. Add github-tags coverage (mirroring github-releases): a renovate/github-tag label and a github-tag commit scope, plus the label in the shared catalog.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Why
Two problems surfaced when I test-dispatched the APM Sync workflow:
apm updatecan't bump exact tag pins. Verified live against.github'sapm.yml(ai-toolkit#v0.1.1):apm outdatedsaysv0.1.1 → v0.2.0 outdated, butapm updatere-resolves the same exact tag and leaves it atv0.1.1. So the scheduled apm-sync-via-apm updatemodel is a no-op for tag-pinned deps — which is everything, sincerangeStrategy: "pin"is the org default.apm-version: "0.21.0", but microsoft/apm release tags arevX.Y.Z, so theaka.ms/apm-unixinstaller built…/download/0.21.0/…→ 404. (This was the failing CI run.)The fix: let Renovate maintain the tag (as you suggested)
.renovate/customManagers.json5— new custom manager trackingowner/repo#vX.Y.Ztag pins underdependencies.apminapm.ymlagainstgithub-tags. Renovate now opens a normalv0.1.1 → v0.2.0PR — version-aware, with the existing 14-day soak, grouping, and changelog links..github/workflows/apm-materialize.yml— new workflow: on any PR that touchesapm.yml, runapm installto re-resolveapm.lock.yamland redeploy the primitives, then commit the result back onto the PR branch (App token → CI re-runs). This completes Renovate's text-only bump. Installsapmviapip install apm-cli(clean onubuntu-24.04, nov-prefix gotcha).apm-sync-caller.yml— the broken scheduled caller (feat(apm): activate apm-sync on the .github consumer #195), superseded by the above.docs/apm-sync-onboarding.mdto the new model.Verified locally
apm installwith the pin bumped to#v0.2.0re-locks tov0.2.0and deploys the new instruction primitive (.github/instructions/devsecninja-conventions.instructions.md). ✅pip install apm-cli==0.21.0→ workingapm. ✅Notes
apm-sync.ymlreusable (released in v1.8.0) still exists; it's now superseded by this model for tag-pinned consumers. Left in place to avoid churn — can be deprecated in a follow-up.workflow_callreusable yet). If a second consumer adopts it, I'd extract a reusable + config-sync template.RELEASE_PLEASE_APP_*identity — the naming-cleanup is already tracked in Rename the "Release Please" GitHub App to a generic automation identity #197.