fix: create GitHub release with assets attached, not after publish - #434
Merged
bmtcril merged 1 commit intoAug 27, 2026
Conversation
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it 422s every time, which is what happened on v4.1.0 (issue openedx#433). Matches the fix already proven and merged on openedx/sample-plugin#57: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
|
Thanks for the pull request, @irfanuddinahmad! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
irfanuddinahmad
added a commit
to irfanuddinahmad/ccx-keys
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/openedx-filters
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/openedx-ledger
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/edx-enterprise
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/openedx-chem
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/auth-backends
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/openedx-authz
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/xss-utils
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/event-routing-backends
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/event-bus-kafka
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/event-bus-redis
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/edx-enterprise-subsidy-client
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/edx-enterprise-data
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/enterprise-integrated-channels
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/taxonomy-connector
that referenced
this pull request
Aug 27, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
Contributor
|
@irfanuddinahmad go ahead and ping me when this is ready and I'll merge it. Thanks for the fix, I hadn't had time to dig and was totally baffled. |
bmtcril
approved these changes
Aug 27, 2026
irfanuddinahmad
added a commit
to irfanuddinahmad/opaque-keys
that referenced
this pull request
Aug 28, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/openedx#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).
irfanuddinahmad
added a commit
to irfanuddinahmad/openedx-core
that referenced
this pull request
Aug 28, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/openedx#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).
irfanuddinahmad
added a commit
to irfanuddinahmad/openedx-calc
that referenced
this pull request
Aug 28, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).
irfanuddinahmad
added a commit
to irfanuddinahmad/edx-rest-api-client
that referenced
this pull request
Aug 28, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/openedx#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).
This was referenced Aug 31, 2026
bmtcril
pushed a commit
that referenced
this pull request
Sep 2, 2026
…ormance release.yml (added in #425, touched again in #434/#435/#436/#438) had drifted from the org's gold-standard reference (sample-plugin's release.yml): python-semantic-release, actions/upload-artifact and actions/download-artifact were on floating version tags (@v10.6.2, @v7, @v8) instead of pinned commit SHAs, defeating the whole point of the pin-actions-to-sha effort (this repo's own #407) for the one workflow that runs unreviewed on every push to master. Also: - Drop `fetch-depth: 0` from the release job's checkout: python-semantic- release auto-deepens a shallow clone itself before evaluating version history, so it's never needed here (confirmed against sample-plugin). - Add `if-no-files-found: error` to the dist upload step so a build that silently produces no artifacts fails loudly instead of shipping an empty release. - Add the `github.ref_name == 'master'` guard to publish_to_pypi's `if:`, matching sample-plugin, even though this workflow currently only triggers on push to master. All three added SHAs were independently verified against the upstream repos via `gh api repos/<owner>/<repo>/commits/<sha>` and cross-checked against their claimed tags (resolving through the annotated tag object for python-semantic-release@v10.6.2, which points at commit 9a026e9303981c866c3425723009becb2437c757). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
irfanuddinahmad
added a commit
to irfanuddinahmad/event-bus-redis
that referenced
this pull request
Sep 7, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to irfanuddinahmad/openedx-filters
that referenced
this pull request
Sep 7, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
irfanuddinahmad
added a commit
to openedx/enterprise-integrated-channels
that referenced
this pull request
Sep 7, 2026
This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.
UsamaSadiq
added a commit
to openedx/edx-rest-api-client
that referenced
this pull request
Sep 21, 2026
…ase (#462) * refactor: move package to src/ layout Move edx_rest_api_client/ to src/edx_rest_api_client/ per the org-wide decision on openedx/public-engineering#506 (2026-07-15): src/ layout is in scope for this modernization cycle so that editable installs resolve correctly under tools like mypy (see https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/). Update setup.py, .coveragerc, and tox.ini to reference the new path so the repo remains buildable/testable with the existing pip-based tooling until pyproject.toml formalizes the src/ layout in the next commit. * feat: consolidate package metadata into pyproject.toml Replace setup.py with PEP 621 static metadata in pyproject.toml: - name, description, classifiers, dependencies as a static list - SPDX license expression + license-files (PEP 639) - setuptools-scm for git-tag-derived versioning (dynamic version) - setuptools packages.find configured for the src/ layout - coverage configuration moved from .coveragerc into [tool.coverage.*] Remove the hardcoded __version__.py module; __version__ is now read via importlib.metadata at runtime (falls back silently if the package isn't installed), so it can no longer go stale relative to the git tag that setuptools-scm derives the build version from. * feat: switch dependency management from pip-compile to uv - Add PEP 735 [dependency-groups] (test-base, test, django42, quality, ci, dev) to pyproject.toml, with a Django 42/52 version matrix via [tool.uv].conflicts - Add [tool.edx_lint].uv_constraints and generate [tool.uv].constraint-dependencies via `edx_lint write_uv_constraints` - Generate and commit uv.lock - Delete requirements/ (pip-compile inputs/outputs); drop the now-stale references in MANIFEST.in - tox.ini: use tox-uv's uv-venv-lock-runner and dependency_groups instead of deps/-r requirements files - Makefile: requirements/test/upgrade targets now use uv sync/uv run tox/uv lock instead of pip-compile and pip-sync - CI: use astral-sh/setup-uv (SHA-pinned) instead of a separate actions/setup-python + pip install step; run tests via `uv run tox`; name matrix jobs by toxenv; add contents: read permissions and fetch-depth: 0 (so setuptools-scm can see tags); add a workflow_call trigger so release.yml can reuse this workflow * feat: add semantic-release and commitlint workflows - Add [tool.semantic_release] to pyproject.toml (build via `python -m build` with SETUPTOOLS_SCM_PRETEND_VERSION; major_on_zero = false, allow_zero_version = true) - Add release.yml: runs CI via workflow_call, then python-semantic-release cuts the release and publishes to PyPI via OIDC trusted publishing (id-token: write, no stored credentials). Actions are pinned to plain version tags (matching openedx/XBlock's production release.yml) except pypa/gh-action-pypi-publish, which is pinned to its verified commit SHA because @release/v1 is a floating branch, not a tag (root cause of a real production failure in xblocks-core's release run) - Remove publish_pypi.yml: it published on `push: tags` using a stored PYPI_UPLOAD_TOKEN and an unpinned @release/v1 ref; once semantic-release starts pushing version tags this would race with release.yml's OIDC-based publish for the same version - commitlint.yml already existed and needed no changes Pre-flight check: latest git tag v7.0.0 matches the actual latest version on PyPI, so the first semantic-release run will compute a correct next version rather than a stale/lower one. * feat: enable python-semantic-release changelog generation changelog: "false" was blindly copied from the sample-plugin reference template in release.yml with no ticket ever requiring it -- CHANGELOG.rst was never deleted and is still hand-maintained. Wire up PSR to update it automatically going forward instead of disabling it outright. - Remove changelog: "false" from release.yml's python-semantic-release step - Add [tool.semantic_release.changelog] (mode = "update", insertion_flag) and [tool.semantic_release.changelog.default_templates] (CHANGELOG.rst, rst) to pyproject.toml - Add the ".. changelog-insertion-marker" line to the top of CHANGELOG.rst so PSR's update mode inserts new version sections above it, leaving the existing hand-written history untouched - Set tag_format = "v{version}" explicitly to match this repo's actual tag convention (v7.0.0, v6.2.0, ...) rather than relying on PSR's untested default * fix: disable python-semantic-release changelog generation Set changelog: "false" on the PSR release step and remove the [tool.semantic_release.changelog] config / insertion marker. Checked against openedx/XBlock's actual production release.yml (the one repo in this effort that has cut real automated releases) -- every run passes changelog: false and invokes `semantic-release -v version --no-changelog`, and the repo has zero github-actions[bot] commits ever. The auto-changelog config this migration previously added was only ever verified via a local dry-run prototype, never against a real release. feanil flagged the same issue on openedx/DoneXBlock#388: "I thought we were not going to add changelogs since they can't be updated by python-semantic-release the way we have it setup." * fix: drop tox from Makefile's quality target Inline tox.ini's [testenv:quality] commands via uv run/uv sync instead of shelling out to `uv run tox -e quality`, matching the no-tox-in- Makefile convention already used elsewhere. tox.ini itself is untouched. * fix: create GitHub release with assets attached, not after publish This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476). * fix: bring release.yml into conformance with sample-plugin gold standard Several action pins had drifted from openedx/sample-plugin's verified release.yml (the org's Phase 3 conformance reference for openedx/public-engineering#506): - actions/checkout was pinned to v6.0.2 (de0fac2...); bump to the verified v7.0.1 SHA (3d3c42e...). - The release job's checkout also carried fetch-depth: 0, which python-semantic-release never needs (it auto-deepens a shallow clone itself before evaluating version history) and which sample-plugin's reference does not set. - python-semantic-release and the upload/download-artifact steps were pinned to bare floating tags (@v10.6.1, @v7, @v8) instead of pinned commit SHAs -- exactly the kind of unpinned action this org's modernization effort is meant to close off. Pinned to verified SHAs for the current versions (v10.6.2, v7.0.1, v8.0.1 respectively). - pypa/gh-action-pypi-publish was correctly SHA-pinned but one version behind (v1.14.1); bumped to the verified v1.14.2 SHA. - The upload-artifact step was missing if-no-files-found: error, so a build that silently produced no dist/ files would upload nothing and the workflow would report success anyway. - publish_to_pypi's `if:` was missing the github.ref_name == 'master' guard sample-plugin's reference uses alongside needs.release.outputs.released == 'true'. Every SHA above was independently re-verified against its action's own commit and tag history (resolving annotated tags one level to their commit) rather than trusted at face value, per this org's history of fabricated/swapped SHAs in this exact file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: drop unneeded fetch-depth: 0 from ci.yml checkout setuptools-scm (used for this package's dynamic version) has fallback_version = "0.0.0" configured in pyproject.toml, so a shallow clone without tag history never fails the build -- it just resolves to the fallback version. Nothing downstream parses or splits __version__ (checked src/edx_rest_api_client/client.py and its tests): it's only ever interpolated as a plain string into the User-Agent header. sample-plugin's own backend-ci.yml does not set fetch-depth: 0 either. Same reasoning already confirmed safe on opaque-keys#461. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: address review feedback (author metadata, stray classifier) - Author metadata matches the org-wide convention used elsewhere in this migration (Open edX Project / oscm@openedx.org). - Drop the Python 3.11 classifier -- CI has only ever tested 3.12, both before and after this migration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: remove unnecessary try/except around __version__ (not present pre-migration) * fix: remove fail-fast: false (not present pre-migration) --------- Co-authored-by: irfanuddinahmad <irfanuddinahmad@users.noreply.github.com> Co-authored-by: Irfan Ahmad <irfan.ahmad@A006-01919.local> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Usama Sadiq <usama7274@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #433. This repo has immutable releases enabled, which freezes a release's assets the moment it's published -- the old flow (main PSR step publishes the release, a separate
publish-actionstep attaches assets afterward) can never work under that constraint. That's why v4.1.0's release ended up with zero assets and PyPI never got the upload.Matches the fix already proven and merged on
openedx/sample-plugin#57: build without publishing (vcs_release: false), then create the release withdist/*attached in onegh release createcall, so assets are in place before the release goes live.Once merged, this commit's own
fix:type will trigger a real release (4.0.2 -> 4.1.1) -- the first real end-to-end test of the corrected pipeline, and it naturally backfills the stuck 4.1.0 gap since 4.1.1 will supersede it with a working release.