ci: dispatch rpk connect plugin docs regeneration on releases - #4636
ci: dispatch rpk connect plugin docs regeneration on releases#4636JakeSCahill wants to merge 2 commits into
Conversation
The rpk connect plugin publishes to the rpk plugin manifest on every release, independent of Redpanda releases, so its command docs in redpanda-data/docs go stale between full rpk doc regenerations. Dispatch update-rpk-plugin-docs alongside the existing docs dispatches so the docs repo refreshes only the connect subtree of its rpk snapshot and opens a PR.
|
@mmatczuk could you take a look when you have a moment? One-step addition to the existing docs dispatches in |
|
cc: @josephwoodward |
The Trigger docs updates step runs inside update-downstream, which notify-slack declares as a dependency. Any dispatch failure (token, API, network) therefore failed update-downstream and silenced the release Slack notification. The step is now allowed to fail; this also covers the pre-existing docs-ui and rp-connect-docs dispatches, which had the same property.
|
Pre-emptive hardening in 798262a, prompted by a review finding on the equivalent cloudv2 sender (redpanda-data/cloudv2#28552): the |
| continue-on-error: true | ||
| env: | ||
| GH_TOKEN: ${{ env.ACTIONS_BOT_TOKEN }} | ||
| run: | | ||
| gh api repos/redpanda-data/docs-ui/dispatches -f event_type=update-go-mod | ||
| gh api repos/redpanda-data/rp-connect-docs/dispatches -f event_type=generate-rpcn-docs | ||
| gh api repos/redpanda-data/rp-connect-docs/dispatches -f event_type=test-cookbook-examples | ||
| # Regenerate the rpk connect plugin docs in redpanda-data/docs. The | ||
| # docs workflow (update-rpk-plugin-docs.yml) refreshes only the | ||
| # connect subtree of its rpk command snapshot and opens a PR per | ||
| # eligible docs branch. | ||
| gh api repos/redpanda-data/docs/dispatches \ | ||
| -f event_type=update-rpk-plugin-docs \ | ||
| -f 'client_payload[plugin]=connect' \ | ||
| -f "client_payload[version]=${GITHUB_REF_NAME#v}" |
There was a problem hiding this comment.
The four dispatches aren't independent of each other, so continue-on-error makes an early failure silent rather than best-effort.
GitHub Actions runs run: blocks with bash -e -o pipefail, so the first failing gh api aborts the rest of the script. If the docs-ui dispatch fails (token, API, network — exactly the cases the commit message cites), the two rp-connect-docs dispatches and the new redpanda-data/docs dispatch never execute. Previously that at least turned the job red; now the job goes green and the release Slack notification reports success while up to three docs regenerations were skipped with no signal.
Suggested fix: run each dispatch as its own independent unit (separate steps, each continue-on-error: true, or one step per dispatch guarded so a failure doesn't abort the others) and emit a warning / $GITHUB_STEP_SUMMARY line for any dispatch that failed, so a swallowed failure is still observable.
Summary
The
rpk connectplugin releases weekly-ish and publishes straight to the rpk plugin manifest, but its command docs in redpanda-data/docs only refresh when a Redpanda release triggers full rpk doc regeneration — so they drift for weeks at a time.This adds one dispatch to the existing Trigger docs updates step in the
update-downstreamjob:update-rpk-plugin-docswith{plugin: connect, version}. The docs workflow (docs#1834) installs that connect version against an rpk binary matching its committed command snapshot, refreshes only the connect subtree, and opens a docs PR against each eligible docs branch (currently main and beta).Details
ACTIONS_BOT_TOKENalready present in the step for the other docs dispatches.push+!contains(ref_name, '-')), so RCs and prereleases never dispatch.Generator side is validated against the docs repo's real snapshots (details in docs-extensions-and-macros#225).