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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 30, 2021, 11:46 UTC
Message-ID: <nycvar.QRO.7.76.6.2111301239480.63@tvgsbejvaqbjf.bet>
In-Reply-To: <211129.86k0grf7lj.gmgdl@evledraar.gmail.com>

Hi Ævar,

On Mon, 29 Nov 2021, Ævar Arnfjörð Bjarmason wrote:

Show 26 quoted lines

> On Fri, Nov 26 2021, Matthias Aßhauer wrote:
>
> > On Fri, 26 Nov 2021, Johannes Schindelin wrote:
> >
> >> Hi,
> >>
> >
> > [...]
> >
> >> One thing I had not thought of earlier: do we really want to do this in
> >> every fork of git/git? I know for a fact that microsoft/git has a very
> >> different workflow upon pushing a tag.
> >>
> >> So maybe we need something like this, too:
> >>
> >>   create-gh-release:
> >> +    if: github.repository == 'git/git'
> >>     name: Create a new release or update an existing release in the GitHub repository
> >
> > I think you're right. This would have unidesirable side effects if it
> > ran in forks.
>
> 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.

> I don't know how much that matters in this case, but I don't see why
> we'd hardcode repository paths in general since we've got the ci-config.

Integrating it into `ci-config` is not even possible in this instance because the newly-introduced workflows should only ever run on tags, while the `ci-config` step is part of a workflow that needs to run on every new push and PR.

Those are two very, very different things. So even if it would have made sense to use `ci-config` in the workflow under discussion, it is not applicable because that step lives in a different workflow that is triggered for a different set of events.

Ciao, Johannes