Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
kloczek opened this issue Aug 31, 2023 · 7 comments · Fixed by #282
Closed

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

kloczek opened this issue Aug 31, 2023 · 7 comments · Fixed by #282

Comments

@kloczek
Copy link

kloczek commented Aug 31, 2023

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
Copy link
Collaborator

2bndy5 commented Aug 31, 2023

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
Copy link
Owner

jbms commented Aug 31, 2023

Sounds good to me.

@2bndy5
Copy link
Collaborator

2bndy5 commented Aug 31, 2023

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
Copy link
Author

kloczek commented Aug 31, 2023

@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
Copy link
Collaborator

2bndy5 commented Aug 31, 2023

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.

@2bndy5 2bndy5 mentioned this issue Aug 31, 2023
kloczek referenced this issue in mesonbuild/meson-python Sep 5, 2023
kloczek referenced this issue in netaddr/netaddr Sep 19, 2023
kloczek referenced this issue in malthe/chameleon Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants