Re: [PATCH] githubci: add a workflow for creating GitHub release notes
- From
Fabian Stelzer <fs@gigacodes.de>
- Date
- Dec 3, 2021, 08:33 UTC
- Message-ID
- <20211203083334.tziwuhbg2u4lsslt@fs>
- In-Reply-To
- <xmqqy252u8t7.fsf@gitster.g>
On 02.12.2021 11:05, Junio C Hamano wrote:
Show 29 quoted lines
>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > >>> Rather than hardcode given repositories, which e.g. for testing the CI >>> itself can be bothersome, perhaps a better thing is to put this into the >>> existing ci-config? I.e. git/git.git could opt itself in to behavior >>> that would be off by default? >> >> You probably missed that the purpose of this workflow is something that >> does not make sense in the forks of git.git. >> >> Its purpose is to create releases for all tags that are pushed to the >> repository. Most forks of git.git have no business creating releases, and >> those that do already have their own processes in place. >> >> As such, the situation is very different from the CI/PR runs that some >> contributors might want to restrict to only certain branches in their >> forks. > >All true. But https://github.com/git/git/ itself has no business >creating releases, as we already have the release process that >pushes the release material to kernel.org to be distributed from >there. > >So... do we still need to discuss this patch? In other words, >what's the benefit of creating "releases for all tags that are >pushed to the repository" there? Does it give us redundancy in case >kernel.org goes down? Does it risk confusing users having to wonder >release materials from which source is more "genuine"? >
One benefit that I see is that github offers APIs & Notifications around releases and lots of CI integration already exist for it. If my (non github) CI includes building the git source then i can easily trigger when upstream releases a new version. Just pulling the repo and watching for the tag works just as well of course.
However the "which source is genuine" is a valid objection. You certainly don't want the CI to accidentally create a new release that does not exist on kernel.org (yet).