Automate Versioning, Release, and PyPI Publishing #425
Conversation
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## next #425 +/- ##
==========================================
+ Coverage 90.07% 90.20% +0.12%
==========================================
Files 2 2
Lines 262 296 +34
==========================================
+ Hits 236 267 +31
- Misses 26 29 +3 ☔ View full report in Codecov by Sentry. |
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
isnt there a way to set this as a dev dependency? Since it is a pipy package
shouldnt we also add --local? I may be misunderstanding, but without the local flag, the hooks will be available in all git projects system wide |
Yeah! I searched about it and found that it is possible. I found that using I'll change it ASAP. Update 1: I was wrong. Adding a poetry plugin as a project dependency doesn't seem to be possible. See python-poetry/poetry#5729 (comment). This should be manually done by each one developing the package :( |
According to |
**TL;DR: this post-commit hook ensures that valid versions are automatically tagged based on changes in the `pyproject.toml` file.**
This post-commit hook automates the tagging of the project based on changes in the `pyproject.toml` file. Here's a breakdown of what it does:
**1. Extracting the version number:**
* `git diff HEAD^..HEAD`: This line compares the current commit (`HEAD`) to its immediate predecessor (`HEAD^`).
* `-- "$(git rev-parse --show-toplevel)"/pyproject.toml`: This specifies the `pyproject.toml` file within the project root directory.
* `grep -m 1 '^\+.*version'`: This searches for the first line starting with a "+" and containing the word "version".
* `sed -s 's/[^A-Z0-9\.\-]//g'`: This removes any characters except numbers, letters, dots, and hyphens from the matched line.
* `version=`: Finally, the extracted version string is stored in the `version` variable.
**2. Validating the version format:**
* `if [[ ! $version =~ ^([0-9]+)\.([0-9]+)\.([0-9]+)(\-[A-Z]+\.[0-9]+)?$ ]]; then`: This checks if the extracted version string matches a specific format:
* `^`: Starts with the beginning of the string.
* `([0-9]+)`: Matches one or more digits (major version).
* `\.`: Matches a literal dot.
* `([0-9]+)`: Matches one or more digits (minor version).
* `\.`: Matches a literal dot.
* `([0-9]+)`: Matches one or more digits (patch version).
* `(\-[A-Z]+\.[0-9]+)?`: This is optional and matches a hyphen followed by one or more uppercase letters and a dot and another number (pre-release + build information).
* `$`: Matches the end of the string.
* If the format is invalid, it logs a message and exits with an error code.
**3. Creating the tag:**
* `git tag -a "v$version"`: This creates a new annotated tag named `v$version` (with the prefix "v") using the extracted version number.
* ``-m "`git log -1 --format=%s`"``: This sets the tag message with the full commit message of the current commit.
* `echo "Created a new tag, v$version"`: This prints a confirmation message.
Co-authored-by: Darwish Ahmad Herati <[email protected]>
This GitHub Actions workflow automates two tasks: 1. **Create Release:** - Triggered when a new version tag (formatted as `vX.X.X`) is pushed. - Creates a release with the tag name, marking it as the latest version. 2. **Publish to PyPI:** - Runs after the release is created successfully. - Builds and publishes the Python package to PyPI using Poetry. - Ignores development requirements during the publishing process. This ensures that each new version gets a release on GitHub and the corresponding Python package is published on PyPI. Co-authored-by: Darwish Ahmad Herati <[email protected]> Co-authored-by: mateuslatrova <[email protected]>
firilisinof
force-pushed
the
release-and-publish-ci
branch
from
dd8fca3 to
0e4ffbe
Compare
- Add instructions to setup git-hooks and poetry-bumpversion plugin
firilisinof
force-pushed
the
release-and-publish-ci
branch
from
0e4ffbe to
703d809
Compare
|
Since I have no permission to set the secret, I have been reaching out to @bndr to set it but I've got no response for the last couple months. Maybe he is busy, but this wont be merged until the secret is set so sadly this pr might be dead. I truly appreciate all the work put into it and apologize for this, I probably should have explored this issue before allowing work to be done on this |
alan-barzilay
force-pushed
the
next
branch
3 times, most recently
from
07a4a64 to
64fc5a2
Compare
|
Hi @alan-barzilay getting back to this, is this still up to date? I think we can start thinking about merging it! |
|
Hi @jonas-eschle, I saw I was tagged in several pull requests today, and instead of responding to each one individually, I thought it might be better to write here to give some broader context — both about my involvement with the project and some of the structural challenges that remain. First, thanks for stepping in and contributing. I hadn't seen your name in earlier activity, but it looks like you've recently taken on a more active role. Were you added as a maintainer by @bndr? And are you in contact with him? For some context: I was previously added as a maintainer, eventually I gathered a team and we worked on a few releases of pipreqs. During that time, we handled a lot of backlog and implemented some long-requested features — including support for Jupyter notebooks, which had been a consistent ask from the community since early on. While doing that work, I came up against some limitations: as a maintainer (but not the repo owner), I couldn't manage contributor access or configure things like repository secrets. I reached out to @bndr about potentially creating a GitHub organization or transferring ownership, but I never got a response regarding this issue or any of the others I raised, which made it challenging to keep the project moving forward in a sustainable way. At this point, I’m no longer involved with the project and don’t plan to return to active maintenance given its current state. That said, I’m glad to see new activity, and I do hope the project continues to evolve. If there’s ever interest in transitioning pipreqs to a GitHub organization or if you’d like to talk about ways to improve the project or its long-term sustainability, I’d be happy to chat. I can provide a throwaway email if you'd prefer to connect directly and streamline that discussion. Thanks again for stepping in and helping keep the project going. Best of luck moving things forward! |
iirc this will fail and can't move forward without setting a repo secret, which only the owner can do |
|
Hi @alan-barzilay ,
First of all, thanks for all the work you've done so far for the repo already
I think this could be beneficial, please just write an e-mail and we can take it from there, thanks for proposing this!
|
|
4 participants
Pull Request Description
This pull request introduces a Git hook and a GitHub actions workflow to automate versioning, release creation, and PyPI publishing. I have closed the previous PR, #411, leaving it for testing. If this PR passes, we will need to close the #408 PR as well. Here's a summary of the changes:
GitHub Actions Workflow:
vX.X.X) is pushed.Git Hook:
pyproject.tomland create a corresponding version tag.Poetry bumpversion plugin
Testing this PR
./git-hooks/directory so that it becomes visible to git hooks.git config core.hooksPath .git-hooks.poetry self add poetry-bumpversion.poetry version <major|minor|...>(this will change bothpyproject.tomlandpipreqs/__init__.py).pyproject.tomlandpipreqs/__init__.py.git push <remote> <tag>.Additional Notes
PYPI_TOKENexists.with:on line 30.TEST_PYPI_TOKEN(make sure that you create it on Test PyPI and added it on GitHub Action secrets).