ReviewOS

stacks/buddy

Complete the packageRules engine: version matchers, schedules, and PR-metadata threading

#1395
Closed chris opened this 9 days ago ·
9 days ago

Follow-up to #1384, which landed the matchers, effects, resolution and scan-path integration.

Remaining matchers

  • matchCurrentVersion — needs a semver range matcher (resolveRuleEffects already has the update in hand)
  • Rule-level schedule — gate which updates may be proposed in the current cron window

Threading effects into PRs

  • createPullRequests still reads flat config for labels/reviewers/assignees; it should call mergeGroupEffects for the group it is about to open
  • prPriority should order groups before the maxPRsPerRun cap is applied
  • groupName should feed groupUpdatesByConfig instead of the parallel legacy path

Migration

  • Extend ConfigurationMigrator.migrateFromRenovate to map Renovate packageRules onto ours (matchPackageNames/matchPackagePatterns → matchPackages, matchDepTypes, matchUpdateTypes, matchFileNames → matchFiles, automerge, labels, groupName, schedule). Currently flagged incompatible; the target shape now exists.

Validation and docs

  • config-validation.ts entries for packages.rules (matcher syntax, unknown fields, empty-matcher rules should require an explicit matchPackages: ['*'])
  • docs/config.md rules section with a cookbook: hold back majors on one package, auto-merge types-only patches, per-workspace reviewers, weekend-only majors
9 days ago

Landed in 12d282f.

matchCurrentVersion and rule-level schedule both added. The schedule is a cron window, not a firing minute — a run is not instantaneous, so a rule that only applied during the exact minute would be a coin toss. A malformed expression matches nothing rather than everything: treating a typo as 'always' would mean a schedule the user believed was holding updates back was doing nothing.

Effects now reach pull requests. Labels/reviewers/assignees union with flat config; prPriority orders groups before the per-run cap (after it would be decorative); groupName feeds the same grouping path as legacy groups; autoMigrate resolves inclusively across a group, unlike auto-merge.

Validation rejects a matcherless rule unless it says matchPackages: ['*'], and treats an unknown key as an error — a typo'd matcher does not disable a rule, it widens it.

Renovate migration now maps rules onto rules. The old path flattened them into legacy groups, which cannot express matchers, so a rule scoped to minor+patch silently became one that also matched majors. Cookbook added to docs/config.md.

Sign in to comment on this issue.