Closed kloczek closed 12 months ago
It was discussed and concluded that we'd start doing full GH releases when we left beta, but you make a good point: RSS feeds. And, it looks like we'll be in beta for a long time (dev cycle is periodic)... Auto-generating a changelog was also part of the same discussion, and it was concluded that we'd start that when we started using GH releases.
We could have the CI create a GH release when a commit is tagged. I especially like GH's newer feature that auto-generates a list of changes since last release/tag. @jbms What do you think?
@kloczek There are other ways to subscribe to pypi releases of a package. See this SO answewr.
Sounds good to me.
As for doing this in CI there are a multitude of options on the GH marketplace. In the past, I've used shogo82148/actions-upload-release-asset to upload generated assets (could be useful for providing another avenue of pypi release assets).
I would be remiss if I didn't mention that this could be done with the gh create release
CLI program (which is inherently installed with all GH action runners). I'm kinda leaning toward this option because we wouldn't be giving write access to another third party action.
@kloczek There are other ways to subscribe to pypi releases of a package. See this SO answewr.
As I'm working on Linux/Solaris distribution which currently have almost 4.7k packages only less than 1.1k of those packages are pyton modules. processing pypi RSS works only in case python modules however amongst those 4.7k packages +3k are have source tree in github
[tkloczko@pers-jacek SPECS]$ grep "VCS:.*github.com" *spec | wc -l
3003
gitlab:
[tkloczko@pers-jacek SPECS]$ grep "VCS:.*gitlab" *spec | wc -l
623
In other words use github releases nitrifications is more generic.
using gh release create
seems super simple:
- name: Create a Github Release
if: ${{ startsWith(github.ref, 'refs/tags/v') }}
run: gh release create ${{ github.ref_name }} --generate-notes
Warning I'm going to try and retroactively create GH releases this way before submitting the above patch; repo watchers/subscribers may get plagued with notifications when I do this.
I'm only exploring this as it would complete the community outreach that this issue concerns (& it was part of an older/related discussion).
Generating a changelog is easy with the gh-changelog extension for the GH CLI. There are other tools, for instance ewjoachim/sphinx-github-changelog. But where we host the changelog needs to be decided.
Thank you very much 👍 😄
FYI: To use the GH CLI in CI to create a release, the env var GH_TOKEN
must be set:
- name: Create a Github Release
if: ${{ startsWith(github.ref, 'refs/tags/v') }}
env:
GH_TOKEN: ${{ github.token }}
run: gh release create ${{ github.ref_name }} --generate-notes
I've fixed this for future tagged commits, but it didn't work (in CI; I manually created the release again) for v0.11.8.
Is it possible next time on release new version make the github release to have entry on https://github.com/jbms/sphinx-immaterial/releases? 🤔
I'm asking because only on make gh release is spread notification about new release to those who have set watch->releases. My automation process those notification trying make preliminary automated upgrade of building packages which allow save some time on maintaining packaging procedures.
More about gh releases is possible to find on https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository https://github.com/marketplace/actions/github-release https://pgjones.dev/blog/trusted-plublishing-2023/