Core release workflow does not create the GitHub Release required by docs promotion

Open
#398 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
github-actions, python
Domain
ci-cd, documentation, release

Research direction

Start by comparing .github/workflows/release.yml with .github/workflows/deploy-docs-stg.yml, especially the GitHub Release and PyPI checks and their comments. Trace the tag-triggered and dry-run paths, then add the documented ownership, matching wait condition, release notes, and workflow invariant test described in the acceptance criteria.

Written by the indexing model from the issue text.

Description

Summary

The core package release workflow publishes artifacts to PyPI but does not create a GitHub Release. The production docs promotion workflow waits for both PyPI and a GitHub Release, so the two workflows do not currently form a complete release path.

Verified on main at d505ef5789d8b18e23fd838300b039932dc399ce.

Evidence

  • .github/workflows/release.yml builds, verifies, uploads artifacts, and publishes to PyPI.
  • It has no gh release create, release action, or equivalent GitHub Release job.
  • .github/workflows/deploy-docs-stg.yml polls gh release view "$VERSION" and the PyPI JSON API for up to 30 minutes.
  • That workflow refuses production promotion if either object is absent.
  • Its comments state that release.yml owns the GitHub Release, but the implementation does not.

Actual behavior

A normal v* tag can publish the package while docs promotion waits for a GitHub Release that no workflow creates.

Expected behavior

The automated and documented release path has a clear owner for creating the GitHub Release before production docs promotion checks it.

Acceptance criteria

  • A real tag-triggered release creates the GitHub Release after verified artifacts are available, or an explicit tested runbook step owns it.
  • Manual dry_run=true dispatches never create a GitHub Release.
  • Release notes and artifact ownership are documented.
  • The docs promotion wait condition matches the implemented release sequence.
  • Add a workflow invariant test that prevents the ownership gap from returning.
Dominant language
Python
Stars
1.8k
Forks
76
Avg merge
1h 7m
Merged PRs (30d)
8

Contributor guide

Open the contributing guide

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 reflex-dev/xy

All issues in reflex-dev/xy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.