What happened
PR #3996 was a Dependabot security bump of form-data 2.5.5→2.5.6 in /workspaces/scorecard. The bump changed the hasown dependency range from ^2.0.2 to ^2.0.4, introducing a duplicate resolution in yarn.lock (both hasown@2.0.2 and hasown@2.0.4 present). A human had to manually trigger /fs-fix run yarn dedupe and commit the changed yarn.lock file at 20:46 UTC — over 4 hours after the PR was created — to consolidate the duplicate. The same pattern occurred on the same day on PR #4000 (launch-editor bump in install-dynamic-plugins), which also required manual /fs-fix for yarn dedupe.
What could go better
The repo already solves this problem for Renovate PRs via the yarnDedupeHighest post-update option in .github/renovate.json. However, Renovate has vulnerabilityAlerts disabled, so Dependabot handles security alerts — without the benefit of automatic deduplication. The existing automate_renovate_changesets.yml workflow already triggers on Dependabot PRs (it checks for dependabot[bot] in the author) and has write access to the branch, but only generates changesets — it does not run dedupe. This means every Dependabot security PR that introduces a transitive dependency version change requires manual human intervention to run a mechanical yarn dedupe command. Confidence is high: the pattern is clearly reproducible (two instances on the same day) and the root cause is well-understood (Dependabot lacks Renovate's postUpdateOptions).
Proposed change
Extend the existing automate_renovate_changesets.yml workflow (or create a sibling workflow) to run yarn dedupe in the affected workspace for Dependabot PRs before generating changesets. The workflow already checks out the PR branch with write access and has Node.js set up. The implementation would: (1) detect the affected workspace from the changed yarn.lock path, (2) run yarn install and yarn dedupe in that workspace directory, (3) commit any lockfile changes. This mirrors what the version-bump.yml workflow already does (lines 107-109: yarn dedupe step after version bumps). An alternative approach is to enable vulnerabilityAlerts in .github/renovate.json, letting Renovate handle security updates with automatic deduplication — but this may conflict with the team's current security alerting preferences.
Validation criteria
The next 3 Dependabot security PRs on this repo that introduce transitive dependency changes should have yarn dedupe run automatically without requiring manual /fs-fix intervention. The PRs should arrive with a clean, deduplicated yarn.lock and pass CI without human lockfile maintenance.
Generated by retro agent from #3996
What happened
PR #3996 was a Dependabot security bump of
form-data2.5.5→2.5.6 in/workspaces/scorecard. The bump changed thehasowndependency range from^2.0.2to^2.0.4, introducing a duplicate resolution inyarn.lock(bothhasown@2.0.2andhasown@2.0.4present). A human had to manually trigger/fs-fix run yarn dedupe and commit the changed yarn.lock fileat 20:46 UTC — over 4 hours after the PR was created — to consolidate the duplicate. The same pattern occurred on the same day on PR #4000 (launch-editorbump ininstall-dynamic-plugins), which also required manual/fs-fixforyarn dedupe.What could go better
The repo already solves this problem for Renovate PRs via the
yarnDedupeHighestpost-update option in.github/renovate.json. However, Renovate hasvulnerabilityAlertsdisabled, so Dependabot handles security alerts — without the benefit of automatic deduplication. The existingautomate_renovate_changesets.ymlworkflow already triggers on Dependabot PRs (it checks fordependabot[bot]in the author) and has write access to the branch, but only generates changesets — it does not run dedupe. This means every Dependabot security PR that introduces a transitive dependency version change requires manual human intervention to run a mechanicalyarn dedupecommand. Confidence is high: the pattern is clearly reproducible (two instances on the same day) and the root cause is well-understood (Dependabot lacks Renovate'spostUpdateOptions).Proposed change
Extend the existing
automate_renovate_changesets.ymlworkflow (or create a sibling workflow) to runyarn dedupein the affected workspace for Dependabot PRs before generating changesets. The workflow already checks out the PR branch with write access and has Node.js set up. The implementation would: (1) detect the affected workspace from the changedyarn.lockpath, (2) runyarn installandyarn dedupein that workspace directory, (3) commit any lockfile changes. This mirrors what theversion-bump.ymlworkflow already does (lines 107-109:yarn dedupestep after version bumps). An alternative approach is to enablevulnerabilityAlertsin.github/renovate.json, letting Renovate handle security updates with automatic deduplication — but this may conflict with the team's current security alerting preferences.Validation criteria
The next 3 Dependabot security PRs on this repo that introduce transitive dependency changes should have
yarn deduperun automatically without requiring manual/fs-fixintervention. The PRs should arrive with a clean, deduplicatedyarn.lockand pass CI without human lockfile maintenance.Generated by retro agent from #3996