feat: polish and stabilize the fail-safe release pipeline #2044
Conversation
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
Signed-off-by: badal484 <badal90603@gmail.com>
Signed-off-by: badal484 <badal90603@gmail.com>
Signed-off-by: badal484 <badal90603@gmail.com>
Dependencies like `python-inspector` and `aboutcode-toolkit` rely on `distutils`, which was removed in Python 3.12. This commit adds a shim in `scancodeio/__init__.py` to strictly import `setuptools` (which patches `distutils`) ONLY when running on Python 3.12 or newer. This ensures: - Python 3.10/3.11 use their native `distutils` without interference. - Python 3.12+ get the necessary shim to prevent `ModuleNotFoundError`. - The `run-unit-tests` CI workflow passes across the full matrix. Signed-off-by: badal484 <badal90603@gmail.com>
badal484
force-pushed
the
feat/release-automation-polish
branch
from
1b010b6 to
6eff2bb
Compare
- Add strictly sequential GitHub Actions workflow (test -> release -> publish) - Enforce Conventional Commits with commitizen and pre-commit hooks - Add CONTRIBUTING.md guide for contributors - Remove legacy fragmented release workflows Signed-off-by: badal484 <badal90603@gmail.com>
- Split monolithic workflow into `ci.yml` and `release.yml` - `ci.yml`: strictly enforces quality gates on all PRs and Pushes - `release.yml`: strictly fail-safe release automation on main only - Remove legacy `run-unit-tests.yml` Signed-off-by: badal484 <badal90603@gmail.com>
ci: Verify permissions in workflows Signed-off-by: badal484 <badal90603@gmail.com>
badal484
force-pushed
the
feat/release-automation-polish
branch
from
6eff2bb to
e980512
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Hi everyone! 👋
This PR wraps up the release automation work proposed in Issue #1992. The main goal was to make our CI and release process boring in the best possible way: easy to understand, hard to misuse, and impossible to release broken code.
What changed
Clear separation of responsibilities
I split the workflows into two distinct paths so it’s always obvious what runs when:
ci.yml
Runs on every PR. It’s fast, safe, and checks everything we care about (tests, linting, basic build validation) with no release permissions.
release.yml
Runs only on main. Before tagging or publishing anything, it re-validates the build to make sure nothing slipped through.
Safer permissions
CI is now strictly read-only. Anything that can publish or tag is isolated to the release workflow and only runs when it should.
More human documentation
CONTRIBUTING.md was rewritten to be friendlier and more practical. Instead of listing rules, it explains why we use commit conventions and how they help automate releases safely.
Why this matters
Previously, CI and release responsibilities were a bit mixed together, which made it easier to accidentally couple testing and publishing. With this change:
PRs stay safe and isolated
Releases only happen after a verified, clean build
If anything breaks, the release simply doesn’t happen
No surprises, no partial releases.
Checklist
✅ CI passes on this branch
✅ Release workflow is restricted to main
✅ Documentation is updated and clearer for contributors