Add standalone GitHub Action for plugin publishing

[Patrick-Erichsen]

Summary

ClawHub currently provides an official reusable workflow for plugin publishing:

uses: openclaw/clawhub/.github/workflows/package-publish.yml@v0.12.0

That works and should remain the blessed full workflow, especially for the security-sensitive OIDC/trusted-publishing path. But for external plugin authors, a standalone GitHub Marketplace/composite action would be the more canonical and ergonomic integration surface.

Why

Reusable workflows are good when we want to own the whole job shape: checkout, CLI install, OIDC handling, dry-run/publish behavior, JSON artifact upload, etc.

Most plugin authors, though, expect to add a publishing step to an existing workflow:

- uses: openclaw/clawhub-publish@v1
  with:
    source_path: adapters/openclaw
    dry_run: false
    token: ${{ secrets.CLAWHUB_TOKEN }}

A standalone action would be easier to discover, easier to copy into existing release workflows, and more aligned with common GitHub Actions product integrations.

Proposed Direction

Add an official standalone action, for example one of:

• openclaw/clawhub-publish@v1
• openclaw/clawhub/actions/package-publish@v1
• openclaw/clawhub-publish-plugin@v1

The action should wrap the same clawhub package publish path used by the reusable workflow.

Initial inputs could mirror the reusable workflow where useful:

• source
• source_path
• dry_run
• owner
• version
• tags
• registry
• site
• token

Outputs:

• publish_json
• release_id

Relationship To The Existing Reusable Workflow

Keep .github/workflows/package-publish.yml as the blessed full workflow.

Recommended split:

• Standalone action: canonical public interface for normal plugin repo integration.
• Reusable workflow: full opinionated workflow, especially for trusted publishing/OIDC and teams that want ClawHub to own the job shape.

If OIDC support is too much for v1 of the action, document that secretless trusted publishing should use the reusable workflow initially, while token-based publishing can use the action.

Acceptance Criteria

• There is an official standalone action for publishing ClawHub plugin packages.
• Docs show the action as the simplest recommended integration for plugin authors.
• Existing reusable workflow docs remain available for the full trusted-publishing path.
• The action uses the same CLI/package publish implementation and preserves existing scope/owner validation behavior.
• Examples cover both monorepo source_path and basic repo-root plugin publishing.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
Keep open: this is a protected, security-labeled feature request, and current main still only documents and ships the reusable package-publish workflow rather than a standalone Marketplace/composite action.

Reproducibility: not applicable. this is a feature request rather than a report of broken existing behavior. Source inspection confirms the current supported path is the reusable workflow, with no standalone publish action present on main.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
The security label and token/OIDC publishing boundary make this maintainer-owned design work, not a safe automated fix-PR lane.

Security
Needs attention: The request is security-sensitive because a standalone publish action would handle publishing credentials and could change OIDC trusted-publishing assumptions.

Review details

Best possible solution:

Design a small official publish action that reuses the existing CLI path and docs the token-based flow first, while leaving secretless OIDC trusted publishing on the reusable workflow unless secops approves a new trust model.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a feature request rather than a report of broken existing behavior. Source inspection confirms the current supported path is the reusable workflow, with no standalone publish action present on main.

Is this the best way to solve the issue?

Unclear until maintainer/security design is settled: the requested standalone action is a plausible ergonomic path, but the safest shape is likely token-based v1 plus keeping OIDC on the existing reusable workflow unless the trust boundary is deliberately expanded.

Label changes:

• add P2: This is a normal-priority product improvement with limited immediate blast radius, but it touches publishing credentials and trusted publishing design.
• add impact:security: The requested action would handle CLAWHUB_TOKEN and may affect GitHub OIDC trusted-publishing boundaries.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority product improvement with limited immediate blast radius, but it touches publishing credentials and trusted publishing design.
• impact:security: The requested action would handle CLAWHUB_TOKEN and may affect GitHub OIDC trusted-publishing boundaries.

Security concerns:

• [medium] Define the standalone action trust boundary — convex/lib/githubActionsOidc.ts:162
  Current OIDC verification special-cases the official reusable workflow, so any standalone action support needs an explicit maintainer/security decision about whether it is token-only or allowed to participate in trusted publishing.
  Confidence: 0.88

What I checked:

• Existing integration is a reusable workflow: Current main defines .github/workflows/package-publish.yml under workflow_call with publish inputs such as source_path and outputs such as publish_json and release_id, matching the workflow the issue wants to keep rather than replace. (.github/workflows/package-publish.yml:4, 77624dd70ff7)
• Docs recommend the reusable workflow only: The GitHub Actions section in the CLI docs points plugin repos to openclaw/clawhub/.github/workflows/package-publish.yml@v0.12.0 and documents monorepo source_path, pinning, dry-run, token, and trusted-publishing notes; it does not document a standalone action. (docs/cli.md:557, 77624dd70ff7)
• No standalone publish action exists on main: A repository search for proposed standalone action names and action metadata found no publish action; the only matching result was an unrelated test temp directory prefix. (77624dd70ff7)
• Trusted publishing is intentionally bound to the official reusable workflow: OIDC verification accepts a job_workflow_ref only when it points at openclaw/clawhub and package-publish.yml, and it keeps secretless trusted publishing behind workflow_dispatch; a standalone action would need a security design decision before OIDC support. (convex/lib/githubActionsOidc.ts:162, 77624dd70ff7)
• Protected security surface: CODEOWNERS marks .github/actions/, .github/workflows/, the OIDC verifier, and CLI package publishing as security-sensitive surfaces requiring secops and publishing-area review. (.github/CODEOWNERS:7, 77624dd70ff7)
• Feature provenance: The reusable workflow, OIDC verifier, CLI publish command, and CLI docs in this checkout trace back to commit b753b1f7ab0e27f230468ba926f805e147da040b, the v0.17.0 release-prep commit. (.github/workflows/package-publish.yml:1, b753b1f7ab0e)

Likely related people:

• Patrick-Erichsen: Blame and log show Patrick Erichsen introduced the current reusable workflow, OIDC verifier, package publish command, and docs in b753b1f; CODEOWNERS also lists @Patrick-Erichsen for the Convex OIDC and CLI publishing surfaces. (role: publishing and OIDC area owner; confidence: high; commits: b753b1f7ab0e, 7467cd88cc82, 92dfd8f35af3; files: .github/workflows/package-publish.yml, convex/lib/githubActionsOidc.ts, packages/clawhub/src/cli/commands/packages.ts)
• openclaw/openclaw-secops: CODEOWNERS explicitly routes .github/actions/, .github/workflows/, convex/lib/githubActionsOidc.ts, and CLI package publishing files through this team, which is directly relevant to a publishing action that handles tokens or OIDC. (role: CODEOWNERS security reviewer; confidence: high; commits: b753b1f7ab0e; files: .github/CODEOWNERS, .github/workflows/package-publish.yml, convex/lib/githubActionsOidc.ts)
• Luke: Luke recently touched the package publish command path in 9a2e8d6, clarifying package sync and publish behavior near the requested integration surface. (role: recent adjacent contributor; confidence: medium; commits: 9a2e8d6fea6e; files: packages/clawhub/src/cli/commands/packages.ts)

Remaining risk / open question:

• A standalone action that supports OIDC could accidentally widen the trusted-publishing boundary unless maintainers explicitly decide how it relates to the current official reusable workflow check.
• A token-based v1 is likely safer, but it still needs secret-handling, Marketplace/action metadata, pinning, and docs review before implementation.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 77624dd70ff7.

[dylanzhangzx]

This seems closely related to the public review path discussed in #2272.

If ClawHub adds a standalone publishing action, it may be worth designing it as more than an ergonomic wrapper around clawhub package publish. Even if v1 remains token-based, the action could preserve provenance-style evidence that future review paths can rely on:

• source repository
• source commit / tag
• GitHub Actions workflow run
• package artifact digest
• ClawHub release id
• publish mode: token-based vs OIDC / trusted publishing

That would make the action useful for normal publishing today, while also giving ClawHub a durable evidence layer for future plugin trust tiers, verified community plugins, and source-linked review.

This does not need to block the first version of the action, but defining the metadata boundary early would help avoid a later migration.