From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "Matthias Aßhauer" <mha1993@live.de>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Mahdi Hosseinzadeh via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Mahdi Hosseinzadeh <mdihosseinzadeh@gmail.com>
Subject: Re: [PATCH] githubci: add a workflow for creating GitHub release notes
Date: Mon, 29 Nov 2021 13:49:20 +0100 [thread overview]
Message-ID: <211129.86k0grf7lj.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <AM0PR04MB601972377B5CC2E24B6BA1DFA5639@AM0PR04MB6019.eurprd04.prod.outlook.com>
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?
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.
next prev parent reply other threads:[~2021-11-29 14:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-25 11:36 [PATCH] githubci: add a workflow for creating GitHub release notes Mahdi Hosseinzadeh via GitGitGadget
2021-11-25 20:57 ` Matthias Aßhauer
2021-11-26 13:59 ` Johannes Schindelin
2021-11-26 17:37 ` Matthias Aßhauer
2021-11-29 12:49 ` Ævar Arnfjörð Bjarmason [this message]
2021-11-30 11:46 ` Johannes Schindelin
2021-12-02 19:05 ` Junio C Hamano
2021-12-03 8:33 ` Fabian Stelzer
2021-12-05 1:25 ` Junio C Hamano
2021-12-05 10:54 ` Fabian Stelzer
2021-12-07 0:05 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=211129.86k0grf7lj.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=mdihosseinzadeh@gmail.com \
--cc=mha1993@live.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.