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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

Hi Ævar,

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

> 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