Skip to content

ci: notify zernio-mcp after SDK publication#30

Open
Ooscaar wants to merge 1 commit into
developfrom
ci/notify-mcp-on-sdk-release
Open

ci: notify zernio-mcp after SDK publication#30
Ooscaar wants to merge 1 commit into
developfrom
ci/notify-mcp-on-sdk-release

Conversation

@Ooscaar

@Ooscaar Ooscaar commented Jul 20, 2026

Copy link
Copy Markdown
Member

Why

When the SDK publishes to PyPI, nothing tells zernio-mcp about it. The MCP package sits on an old SDK version until someone notices by hand.

What

A repository_dispatch at the end of both publish pipelines, using the same curl pattern as the Node SDK trigger in the API repo:

- name: Trigger MCP SDK Sync
  if: <same condition as the publish steps above>
  continue-on-error: true
  run: |
    curl -fsS -L -X POST \
      -H "Accept: application/vnd.github.v3+json" \
      -H "Authorization: token ${{ secrets.MCP_DISPATCH_TOKEN }}" \
      https://api.github.com/repos/zernio-dev/zernio-mcp/dispatches \
      -d '{"event_type":"sdk-released","client_payload":{"sdk_version":"...","ref":"${{ github.sha }}"}}'

sdk-released + sdk_version is what zernio-mcp/.github/workflows/sync-sdk.yml listens for and validates. Each step reuses the condition of the publish steps above it, so a run that published nothing notifies nothing.

Workflow files only — no source, tests, or packaging.

Worth a look

  • Secret: MCP_DISPATCH_TOKEN, already configured. (refactor: extract MCP server into standalone repository #29 assumes MCP_REPO_TOKEN, which does not exist here.)
  • -fsS: the reference snippet omits -f, so a 401 exits 0 and still prints ✓ Triggered. With -f the step goes red while continue-on-error keeps the release green. Easy to drop.
  • release.yml will not actually fire. It runs only on push to main (1.4.49 vs develop's 1.4.291, untouched since May), and its last run skipped every publish step because the tag already existed. Added for symmetry and manual releases; generate.yml is what notifies MCP in practice.
  • Out of scope: generate.yml's publish steps still have continue-on-error: true, so a failed upload fires the dispatch anyway. refactor: extract MCP server into standalone repository #29 removes those two lines — needs to land there or as a follow-up.
  • Conflicts with refactor: extract MCP server into standalone repository #29 on both files; whichever merges second needs a rebase.

Validation

YAML parses; dispatch payload is valid JSON and passes the semver regex sync-sdk.yml enforces; referenced step ids/outputs exist; notify step sits after both publishes with a matching condition. Not yet run against the live pipeline.

🤖 Generated with Claude Code

Both publish pipelines now send a repository_dispatch to
zernio-dev/zernio-mcp once the PyPI uploads complete, so the MCP
package can sync against the released SDK version instead of going
stale until someone notices.

Uses the same curl dispatch pattern as the Node SDK trigger in the API
repo. The event type and payload match what zernio-mcp's sync-sdk.yml
consumes: `sdk-released` with a `sdk_version` it validates as semver.

Each step is gated on the same condition as the publish steps above it,
so no notification is sent for a run that published nothing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.

1 participant