Re: [PATCH] githubci: add a workflow for creating GitHub release notes

From: Fabian Stelzer <fs@gigacodes.de>
Date: Dec 5, 2021, 10:54 UTC
Message-ID: <20211205105441.vsgyef3njcggbzku@fs>
In-Reply-To: <xmqqo85vonba.fsf@gitster.g>

On 04.12.2021 17:25, Junio C Hamano wrote:

Show 17 quoted lines

>Fabian Stelzer <fs@gigacodes.de> writes:
>
>> 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.
>
>Ahh, thanks.
>
>If some sort of "push" notification is available only for "there is
>a new release" but not for "there is a new tag", then I can sort of
>see why having a "release" would be nice.  Listening to notifications
>and acting on them is more pleasant than having to poll.
>
>Do I understand what you said correctly?
>

Yes, thats correct.

Github has a webhook for releases: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#release

Getting tags means listening to every push and filtering yourself: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#push

Still, if this gets added to git/git I think the risk of users considering the github release to be the primary source is quite high since lots of tools and CI integrations use them. I'm not a fan of depending on github for everything, but as long as the kernel.org releases don't go away I don't think this is a big deal.