Skip to content

ci: dispatch rpk connect plugin docs regeneration on releases - #4636

Open
JakeSCahill wants to merge 2 commits into
mainfrom
ci/dispatch-rpk-connect-plugin-docs
Open

ci: dispatch rpk connect plugin docs regeneration on releases#4636
JakeSCahill wants to merge 2 commits into
mainfrom
ci/dispatch-rpk-connect-plugin-docs

Conversation

@JakeSCahill

Copy link
Copy Markdown
Contributor

Summary

The rpk connect plugin 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-downstream job: update-rpk-plugin-docs with {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

  • Uses the ACTIONS_BOT_TOKEN already present in the step for the other docs dispatches.
  • Inherits the job's existing guard (push + !contains(ref_name, '-')), so RCs and prereleases never dispatch.
  • Rapid successive releases update the same open docs PR (version-less branch on the docs side), so there's no PR pile-up.

Generator side is validated against the docs repo's real snapshots (details in docs-extensions-and-macros#225).

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.
@JakeSCahill

Copy link
Copy Markdown
Contributor Author

@mmatczuk could you take a look when you have a moment? One-step addition to the existing docs dispatches in update-downstream — it keeps the rpk connect reference docs current on each release. The receiving side (redpanda-data/docs#1834) is reviewed and ready.

@mmatczuk

Copy link
Copy Markdown
Contributor

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.
@JakeSCahill

Copy link
Copy Markdown
Contributor Author

Pre-emptive hardening in 798262a, prompted by a review finding on the equivalent cloudv2 sender (redpanda-data/cloudv2#28552): the Trigger docs updates step runs inside update-downstream, which notify-slack depends on, so any dispatch failure (token, API, network) would have failed the job and silenced the release Slack notification. The step now carries continue-on-error: true — which also protects the pre-existing docs-ui and rp-connect-docs dispatches that had the same property. Docs failures can never affect the release or its notifications.

Comment on lines +263 to +277
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}"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Ref: release.yml#L259-L277

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants