Skip to content

fix: dispatch release workflow after tag creation#103

Open
lucarlig wants to merge 1 commit into
mainfrom
user/luca/auto-dispatch-release-tags
Open

fix: dispatch release workflow after tag creation#103
lucarlig wants to merge 1 commit into
mainfrom
user/luca/auto-dispatch-release-tags

Conversation

@lucarlig
Copy link
Copy Markdown
Collaborator

Summary

  • Fixes Release validation tags should dispatch publish workflow automatically #102.
  • Dispatches release-rust-python-package.yaml explicitly after merge-to-main release tags are created.
  • Grants the tag creation job actions: write so gh workflow run can start the PyPI release workflow.
  • Removes the skipped publish-release-tags reusable job path and covers the new behavior in the catalog workflow test.

Verification

  • actionlint .github/workflows/ci-rust-python-package.yaml
  • python3 tools/plugin_catalog.py validate .
  • python3 -m unittest tests.test_plugin_catalog
  • git diff --check

Signed-off-by: lucarlig <luca.carlig@ibm.com>
@lucarlig lucarlig marked this pull request as ready for review May 22, 2026 13:00
Copy link
Copy Markdown
Collaborator

@msureshkumar88 msureshkumar88 left a comment

Choose a reason for hiding this comment

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

Findings

.github/workflows/ci-rust-python-package.yaml

L437-440: ❓ q: No run ID or URL logged after dispatch. If gh workflow run exits 0 but the triggered run fails immediately (bad ref, auth error), there's no breadcrumb linking the tag to its release run. Consider appending && gh run list -w release-rust-python-package.yaml --limit 1 --json url --jq '.[0].url' to surface the URL in the CI log.

L437: 🟡 risk: Dispatch relies on PUBLISH_ENABLED="" being "not false" in the release workflow's resolve step. The [[ "${PUBLISH_ENABLED}" == "false" ]] guard works today, but if that condition ever changes (e.g., to [[ "${PUBLISH_ENABLED}" != "true" ]]), dispatches via workflow_dispatch silently stop publishing. The workflow_dispatch trigger in release-rust-python-package.yaml should declare publish_enabled as an input with default: true to make the intent explicit.

tests/test_plugin_catalog.py

L2905-2916: 🔵 nit: Tests assert gh workflow run args appear in create_tags_section but don't assert order relative to git push origin. Structural guarantee (dispatch only after push) isn't covered. Low-priority since the YAML diff makes it obvious.


Approach is sound — workflow_dispatch correctly bypasses GitHub's cross-workflow suppression (which blocks push:tags from Actions-created tags). The publish-release-tags removal + inline dispatch is the right fix for #102. Two items worth addressing before merge: log the dispatched run URL (ops hygiene), and add publish_enabled: true as explicit workflow_dispatch input in release-rust-python-package.yaml (can be a follow-up PR if preferred).

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.

Release validation tags should dispatch publish workflow automatically

2 participants