Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

ci: every SDK publish workflow runs on every language's release tag (Python shows a misleading green)

Open Beginner friendly
#88 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, yaml
Domain
ci-cd

Research direction

Start in .github/workflows/publish-py.yml: its build job lacks the if: gate its publish job has, which is why non-Python tags show a green Python run. Read every publish-*.yml in .github/workflows/, add a workflow-level tag filter (or the if: condition) to every job, and standardize on github.event.release.tag_name where github.ref_name is used. Also delete release-py.yml as recommended. Done looks like: cutting a <lang>-sdk-v* tag starts only that language's workflow, with all others absent or skipped.

Written by the indexing model from the issue text.

Description

What we saw

Cutting js-sdk-v0.8.0 (and each other v0.8.0 tag) triggered every SDK publish workflow. They show up in the Actions list under that release's name with mixed results:

  • Publish Python SDK #68: Release js-sdk-v0.8.0 shows success (19s).
  • Publish PHP SDK #63: Release js-sdk-v0.8.0 shows skipped.
  • Publish JavaScript SDK #68: Release js-sdk-v0.8.0 shows success. This is the only one that should run.

What actually happened (no bad publish)

  • publish-py.yml has no workflow-level filter. Its build job (tests + package build) runs on every release, and only the publish job is gated with if: startsWith(github.ref_name, 'py-sdk-v'). So on a JS/Go/Java/PHP/Ruby tag it runs the Python tests, skips publish, and the run reads green. Example: run 37562889995 on js-sdk-v0.8.0 shows build success and publish skipped.
  • The other workflows put the tag filter on their only job, so they show skipped.
  • Net effect: 6 releases × 6 workflows = 36 runs per lockstep release, and a green "Publish Python SDK" on a non-Python tag looks like a Python publish happened.

Related

release-py.yml (a second Python release workflow, using PYPI_TOKEN) runs on every push touching packages/py-sdk/** and has failed with 403 on its last 6 runs. If its token were ever fixed, every py-sdk merge to main would publish to PyPI and race publish-py.yml (which uses OIDC trusted publishing). Recommend deleting it.

Suggested fix

  • Gate each publish workflow at the workflow level so non-matching tags don't start a run. Either use on: push: tags: ['py-sdk-v*'] style triggers, or put if: startsWith(github.event.release.tag_name, '<lang>-sdk-v') on every job (including build).
  • Use github.event.release.tag_name consistently. py and go currently use github.ref_name; the others use release.tag_name.
  • Delete release-py.yml.
  • publish-ruby.yml: RubyGems publish failed "Access Denied" (run 37562896184). The gem has never been published and needs a RUBYGEMS_API_KEY. Scheduled separately.

Low priority: nothing was published wrongly in v0.8.0. Found during the v1.132.0 post-deploy SDK release.

Dominant language
PHP
Stars
1
Forks
0
Avg merge
3d 16h
Merged PRs (30d)
10

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TurboDocx/SDK

All issues in TurboDocx/SDK

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.