Skip to content

Property automation: cloud-sync trigger, workflow hardening, iceberg override cleanup - #1847

Open
JakeSCahill wants to merge 3 commits into
mainfrom
docs-property-automation-fixes
Open

Property automation: cloud-sync trigger, workflow hardening, iceberg override cleanup#1847
JakeSCahill wants to merge 3 commits into
mainfrom
docs-property-automation-fixes

Conversation

@JakeSCahill

@JakeSCahill JakeSCahill commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Implements the docs-repo side of the property automation fixes for DOC-1886 and DOC-1889.

Workflow: cloud-sync trigger and hardening (DOC-1886)

Changes to .github/workflows/update-property-docs.yaml:

  • New trigger-cloud-property-sync dispatch event. When cloudv2 changes cloud property availability metadata, it can dispatch this event to regenerate the property docs without a new Redpanda release. This pairs with a cloudv2 workflow PR that sends the dispatch (placeholder — link will be added). The contract this side expects: event type trigger-cloud-property-sync, optional payload key commit_sha (hex, 7-40 chars). The rpai docs sender that went live 2026-08-03 uses the same repository-dispatch pattern from cloudv2, so the credential path is proven.
  • Tag resolution for cloud-sync. The cloud-sync event resolves the tag from latest-redpanda-tag in antora.yml instead of the dispatch payload, and fails with a clear message if the attribute is missing. Regen always targets the currently published version.
  • Newer-tag guard bypass for cloud-sync. The whole point of a cloud-sync run is a same-tag regen. Doc-tools' same-tag path already skips the diff phase and version bump, so bypassing the guard is safe.
  • Fixed PR branch for cloud-sync (update-property-docs-cloud-sync) so repeat dispatches update one open PR instead of colliding with the release branch. Cloud-sync PRs get a cloud-property-sync label alongside auto-docs, and the PR body includes the triggering cloudv2 commit_sha for traceability (guarded when empty).
  • Concurrency group keyed on workflow + resolved tag/branch so runs targeting the same PR branch queue instead of racing (cancel-in-progress: false).
  • Caching: cache: npm on actions/setup-node, plus a pip cache (~/.cache/pip) keyed on package-lock.json (the pinned doc-tools version determines the Python requirements it installs at run time). The Redpanda clone is deliberately not cached.

Override cleanup: iceberg credentials source (DOC-1889)

docs-data/property-overrides.json had two entries for the same property:

Sequencing notes

  • The override deletion is sequenced with docs-extensions-and-macros#233. Resolved: #233 shipped in doc-tools 5.3.1 on 2026-07-31 and this repo's lockfile is past it, so the override deletion has no interim risk and does not need to wait.
  • --regenerate-old-baseline applies only to manual local --diff runs (it rebuilds a stale committed baseline). This workflow never passes --diff, so the flag is deliberately absent from it — a comment in the workflow now says so.

No generated files are touched in this PR. Regen happens via the automation.

🤖 Generated with Claude Code

@JakeSCahill
JakeSCahill requested a review from a team as a code owner July 29, 2026 11:14
@netlify

netlify Bot commented Jul 29, 2026

Copy link
Copy Markdown

Deploy Preview for redpanda-docs-preview ready!

Name Link
🔨 Latest commit 9a9da44
🔍 Latest deploy log https://app.netlify.com/projects/redpanda-docs-preview/deploys/6a6a4bc2df810d000884116c
😎 Deploy Preview https://deploy-preview-1847--redpanda-docs-preview.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@coderabbitai

coderabbitai Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

The documentation workflow now handles cloud-property-sync dispatches with separate concurrency, cached pip installation, tag resolution from antora.yml, and bypassed version gating. Cloud-sync runs use a fixed branch and customized pull request metadata, while release runs retain tag-specific behavior. Property overrides remove the Iceberg AWS credentials source entry and mark the remaining credentials source property as cluster-scoped. Descriptions for consumer group metrics and seed servers were also updated.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubDispatch
  participant UpdatePropertyDocs
  participant AntoraYml
  participant PullRequest

  GitHubDispatch->>UpdatePropertyDocs: trigger-cloud-property-sync
  UpdatePropertyDocs->>AntoraYml: read latest-redpanda-tag
  AntoraYml-->>UpdatePropertyDocs: documentation tag
  UpdatePropertyDocs->>UpdatePropertyDocs: generate documentation
  UpdatePropertyDocs->>PullRequest: create or update cloud-sync PR
Loading

Possibly related PRs

Suggested reviewers: feediver1

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly summarizes the cloud-sync workflow changes and Iceberg override cleanup.
Description check ✅ Passed The description thoroughly explains both objectives and links the related Jira tickets, but omits the review deadline, page previews, and checks checklist.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch docs-property-automation-fixes

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@JakeSCahill

Copy link
Copy Markdown
Contributor Author

Companion cloudv2 dispatch PR: redpanda-data/cloudv2#28588 (sends the trigger-cloud-property-sync event this workflow now accepts).

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
.github/workflows/update-property-docs.yaml (1)

129-133: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Regenerate the old baseline on the initial sync.

The required --regenerate-old-baseline flag is missing, so the first regeneration after docs-extensions-and-macros#233 will not perform the required baseline migration. Add it for that initial cloud-sync run.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/update-property-docs.yaml around lines 129 - 133, Update
the doc-tools property-docs generation command in the initial cloud-sync
workflow to include the required --regenerate-old-baseline flag, preserving the
existing tag, partials, cloud-support, and overrides options.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/update-property-docs.yaml:
- Line 82: Harden the tag handling in the workflow: at
.github/workflows/update-property-docs.yaml lines 82-82, pass dispatch inputs
through env, read quoted shell variables, and reject control characters before
writing tag to GITHUB_OUTPUT; at lines 144-144, pass steps.tag.outputs.tag
through env and assign it via TAG="$TAG" instead of embedding it directly in the
script.
- Around line 151-159: Validate CLOUD_COMMIT_SHA as a commit hash before the
output-writing block uses it, and reject or sanitize any value containing
newlines or other invalid characters. Update the conditional around
CLOUD_COMMIT_SHA in the workflow’s body generation so only validated values are
emitted, preserving the existing BODY_EOF output format for valid hashes.

---

Outside diff comments:
In @.github/workflows/update-property-docs.yaml:
- Around line 129-133: Update the doc-tools property-docs generation command in
the initial cloud-sync workflow to include the required
--regenerate-old-baseline flag, preserving the existing tag, partials,
cloud-support, and overrides options.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 7784a342-9ebc-4dc0-9df0-4a9ee71bc263

📥 Commits

Reviewing files that changed from the base of the PR and between 4e47021 and b8b58b2.

📒 Files selected for processing (2)
  • .github/workflows/update-property-docs.yaml
  • docs-data/property-overrides.json

Comment thread .github/workflows/update-property-docs.yaml Outdated
Comment thread .github/workflows/update-property-docs.yaml

@micheleRP micheleRP left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Docs-team-standards review

Files reviewed: 2 (.github/workflows/update-property-docs.yaml +110/−12, docs-data/property-overrides.json +2/−8)
Overall assessment: No .adoc files changed, so the style checklist doesn't apply — reviewed as automation and override logic. The workflow hardening is solid and the injection-proofing is genuinely good. Two things need attention before the first dispatch, and the sequencing notes in the description are now out of date in a way worth correcting rather than acting on.

What this PR does

Adds a second repository_dispatch event (trigger-cloud-property-sync) so cloud property availability changes can trigger a same-tag regen without waiting for a Redpanda release. Cloud-sync runs resolve the tag from antora.yml, bypass the newer-tag guard, and land on a fixed branch with an extra label. Also adds npm/pip caching, a concurrency group, and passes all dispatch-controlled values through env instead of interpolating them into shell. Separately deletes a duplicate iceberg override keyed by an old property name and migrates its config_scope to the canonical entry.

Jira ticket alignment

Tickets: DOC-1886 (cloud-sync trigger and hardening), DOC-1889 (override cleanup)

Both addressed. The workflow half maps cleanly to DOC-1886's scope; the override half does what DOC-1889 asks. No generated files touched, consistent with the rule that property partials are only ever regenerated.

Critical issues

None confirmed. Everything checkable came back correct:

  • Tag resolutionlatest-redpanda-tag: 'v26.2.1' is the only match in antora.yml, so the grep | awk | tr chain yields v26.2.1 with no collision risk, and the new ^[A-Za-z0-9._-]+$ guard accepts it.
  • Concurrency expressionaction == '…' && 'cloud-sync' || inputs.tag || client_payload.tag || github.ref resolves correctly for all three trigger types (traced each).
  • Token wiringACTIONS_BOT_TOKEN already comes from Secrets Manager, so cloud-sync PRs will run the repo's checks rather than silently skipping them the way GITHUB_TOKEN auto-PRs do.
  • Link safety of the rename — no prose xref anywhere in docs/modules or cloud-docs/modules points at #iceberg_rest_catalog_aws_credentials_source. The only occurrences are the two shipped JSON attachments (redpanda-properties-v26.1.14.json, -v26.2.1.json) and the override file itself, so the rename breaks no hand-written links.

Suggestions

  1. The cloud-property-sync label does not exist in this repo. gh label list shows only auto-docs (and unrelated cloud separation), there's no label config file in .github/, and no other workflow references the new name. Whether peter-evans/create-pull-request@v6 auto-creates it or fails the step isn't documented either way in GitHub's REST reference. Either way the failure mode is bad: the label is applied after the full clone-and-regen, so a first dispatch could burn the whole run and produce no PR.

    • Fix: create the label (with a colour and description) before the first dispatch. Cheap insurance, and better than an auto-created label with no description.
  2. The --regenerate-old-baseline instruction can't be satisfied by this workflow. The flag does exist on docs-extensions-and-macros main (bin/doc-tools.js:894), but it's absent from the installed 5.3.1 tree, it only affects the --diff code path, and this workflow never passes --diff. So "the first regen after #233 must use --regenerate-old-baseline" describes a manual local run, not anything the automation does.

    • Fix: say so explicitly in the description or a comment on the workflow, otherwise the next person will look for it in the workflow, not find it, and assume it was dropped. It also needs a version bump past the current pin to be available at all.
  3. The sequencing caveat is already satisfied — the override deletion is safe to merge now. docs-extensions-and-macros#233 merged 2026-07-31T15:12Z and is an ancestor of main (compare reports behind_by: 0); its name-resolution fix is present in the installed package, where the BasicInfoTransformer docstring documents the new priority order (first string-literal parameter, falling back to name_in_file). 5.3.1 published 19:17Z the same day, and package-lock.json pins 5.3.2. So there's no window where the old-named property loses its description override — that risk closed on 2026-07-31. Worth updating the note so nobody holds the PR waiting on it.

  4. Confirm the config_scope: cluster migration lands one entry, not two. iceberg_rest_catalog_credentials_source currently renders in topic-properties.adoc:440, between flush.ms and initial.retention.local.target.bytes — an underscore-named property among dotted topic properties, which reads like an existing misfiling. After the rename, the cluster property takes that same name, so the surviving override with config_scope: cluster is doing more than "nothing valuable is lost" implies: it decides where a name that currently appears in the topic file gets filed.

    • Fix: run one local regen before merging and confirm the property appears once, under cluster scope. This is the one change here whose outcome can't be determined by reading.
  5. Cloud-sync and release runs aren't serialized against each other. The groups are <workflow>-cloud-sync and <workflow>-<tag>, so both can run at once, each regenerating the same partials on a different branch. CI is fine; whichever PR merges second conflicts or clobbers. Worth a comment acknowledging it, or key both paths on the resolved tag.

  6. Cloud-sync PRs get a title identical to release PRs (auto-docs: Update property docs for tag v26.2.1), since only branch, labels, and body branch in pr_meta. That defeats part of the point of distinguishing them — you can't tell which trigger fired from the PR list. Consider a distinct title for the cloud-sync path.

  7. Nit: the new bypass branch writes >> $GITHUB_OUTPUT unquoted while the tag step you just hardened uses >> "$GITHUB_OUTPUT".

Impact on other files

  • The property-docs review guide (docs-team-standards) documents the auto-docs flow as "Opens a PR titled auto-docs: Update property docs for tag <version>". There's now a second trigger, a second label, and a long-lived fixed branch that behaves differently from the per-tag release branches. Reviewers triaging these PRs need that context.
  • The paired dispatch-sender PR is still a placeholder in the description. The trigger-cloud-property-sync event type and the commit_sha payload key form a contract that can't be verified from this side until that PR exists. Worth landing them together, or at least confirming the sender uses those exact names.
  • No generated property partials touched, correctly — regen happens through the automation.

What works well

  • Routing every dispatch-controlled value (EVENT_ACTION, INPUT_TAG, PAYLOAD_TAG, CLOUD_COMMIT_SHA) through env instead of direct interpolation is the right call on a workflow that accepts third-party dispatches, and the hex validation on commit_sha closes the heredoc-terminator injection into GITHUB_OUTPUT rather than just sanitising for display.
  • The tag charset check happens before the value reaches GITHUB_OUTPUT, so downstream steps can't be fed a crafted tag.
  • The comments explain why rather than restating the YAML — the guard-bypass rationale and the pip cache key choice both pre-empt the obvious reviewer question.
  • Failing loudly when latest-redpanda-tag is missing, instead of regenerating against an empty tag.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants