Floor doc-tools at ^5.3.1 - #1870
Conversation
The first manual rpk ai plugin dispatch failed because npm ci installed doc-tools from the lockfile, which still pinned 5.2.5 while --plugin shipped in 5.3.0. The dependency bump fixed that instance, but the package.json floor stayed at ^5.1.2, so any future lockfile regeneration could legally resolve below the features the rpk workflows depend on. The floor now matches the oldest version the automation requires.
✅ Deploy Preview for redpanda-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request updates Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
micheleRP
left a comment
micheleRP
left a comment
There was a problem hiding this comment.
Approving. I verified the premise against the actual failure rather than the description.
The run that broke is 30682273251, and the error is exactly what you say:
2026-08-01T03:35:56 error: unknown option '--plugin'
##[error]Process completed with exit code 1
And the range on main is the reason it was allowed to happen: ^5.1.2 legally admits 5.1.2 through 5.2.x, none of which carry --plugin. Flooring at ^5.3.1 turns an implicit assumption ("the lockfile happens to be new enough") into a machine-enforced one, which is the right shape for something the workflows hard-depend on.
I also checked the lockfile churn, since +25/-1075 is a lot of diff to attach to a one-line semantic change. All 88 removed package blocks are under the appium-chromium-driver subtree: 86 carry extraneous: true, and the other two (wbuf, which) are dev/optional entries that npm deduped when it re-resolved. Nothing production-facing. Then I confirmed it actually installs, on a clean clone of this branch:
npm ci -> exit 0
locked -> 5.3.1
installed CLI has --plugin
One scope suggestion, not blocking: v/26.1 also carries update-rpk-docs.yml, reachable by workflow_dispatch, and is still at ^5.1.2. A full regeneration fired there would run without #226's platform detection and without the What's-new rpk ai exclusion from #238, so the same class of silently-wrong output applies even though --plugin is not involved. Worth either flooring that branch too or confirming it no longer regenerates rpk docs.
2 participants
Hardening follow-up from the first production rpk ai dispatch (micheleRP's finding): the run failed because
npm ciinstalled doc-tools from the lockfile at 5.2.5, predating--plugin. The dependency-bump PR fixed the instance, butpackage.jsonstill floored at^5.1.2, so any future lockfile regeneration could legally resolve below the features the rpk workflows depend on. This raises the floor to^5.3.1, the oldest version carrying--plugin, flag extraction, and the What's-new handling the workflows assume.The alternative she suggested (installing doc-tools explicitly in the workflow) is already the pattern in the newer workflows (
npx -p @redpanda-data/docs-extensions-and-macros@^5.3.0in the plugin receiver); this PR closes the gap for the olderupdate-rpk-docs.ymlpath that uses the repo install.Related PRs (rpk docs automation train)
Follow-up to the #1868/#1869 production run.