RFE: is it possible to start making github releases?🤔

[kloczek]

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/

[2bndy5]

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.

[jbms]

Sounds good to me.

[2bndy5]

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]

@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.

[2bndy5]

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.

About generating a changelog

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.

1. If we host a changelog in the repo root, then I think there would have to be a major change to the CI triggers on the main branch. This is because it would have to be auto-pushed for every push to main branch. Although this may be a common practice, I don't think its worth the extra complication to the CI.
2. Hosting a changelog that is auto-generated in our doc's builds makes sense given the nature of this repo's software. Additionally, we wouldn't have to keep the generated changelog checked in with the repo source. Rather it could be generated on every docs build/published on main branch. Finally, we'd only have to add a link to our README that leads to the changelog in our hosted docs.