From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: Emily Shaffer <emilyshaffer@google.com>, git@vger.kernel.org
Subject: Re: GitGitGadget on git/git, was Re: Should we auto-close PRs on git/git?
Date: Fri, 22 Nov 2019 14:50:05 +0100 (CET) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1911221430510.31080@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20191121105414.GA16238@sigill.intra.peff.net>
Hi Peff,
On Thu, 21 Nov 2019, Jeff King wrote:
> On Mon, Nov 18, 2019 at 07:37:57PM +0100, Johannes Schindelin wrote:
>
> > Yeah, it wasn't easy. But then, who does not like a little challenge,
> > especially the challenge to test things outside of production? So here
> > is a PR: https://github.com/gitgitgadget/gitgitgadget/pull/148
> >
> > I trust everybody with even rudimentary Javascript skills to be able
> > to provide useful feedback on that PR.
>
> Wow, thanks for working on this! I don't know that I'd call my
> javascript skills even rudimentary, but I did give it a look. The real
> challenge to me is not the individual lines of code, but understanding
> how the Azure Pipelines and GitHub App systems fit together. So I didn't
> see anything wrong, but I also know very little about those systems.
I actually spent some quality time with the wiki in the past days to
remedy that. You can adore the result in all its beauty here:
https://github.com/gitgitgadget/gitgitgadget/wiki/GitGitGadget's-Azure-Function-and-Azure-Pipelines
> Likewise, the explanations in your comments and commit messages all made
> sense to me. But that may also be a false sense of security. You nicely
> led me through reading the patches, but the likely bug would probably be
> one you did not even anticipate. ;)
Right, but it does help to have somebody cross-check the ideas.
You probably also realized that Chris Webster and Danh looked over them
and provided useful suggestions, which I incorporated. One of those
suggestions was to document the involved Azure Pipelines ;-)
> > To build some confidence in my patches (as you probably know, I do not
> > trust reviews as much as I trust real-life testing, although I do
> > prefer to have both) I "kind of" activated it on my fork, limited to
> > act only on comments _I_ made on PRs (and sending only to me instead
> > of the list), and it seems to work all right, so far. I cannot say for
> > sure whether it handles the PR labels correctly, but I guess time will
> > tell, and I will fix bugs as quickly as I can.
>
> Yeah, that makes sense to me. Going from one repo to three is not much
> worse than going to two, so it's good to have a testing area, too.
>
> Do you want any third-party testing there (e.g., a user who isn't you
> making a PR against dscho/git)?
While that would be nice, my fork is a mess and not really set up to
provide any useful target branch...
The real proof of the concept will come when the first git/git PR will be
submitted.
> > Question is: should I turn this thing on? I.e. install that
> > GitGitGadget-Git App on https://github.com/git/git? This would allow
> > GitHub users to `/submit` directly from PRs opened in that repository. I
> > am sure that there are a few kinks to work out, but I do think that it
> > should not take long to stabilize.
>
> I'd say "yes". The status quo is probably worse than a system with a few
> bugs. The worst case if it's disastrously wasting submitter's time is
> that we turn it back off, but I have faith that you'd just fix the bugs
> before then anyway.
Yes, I hope to be quick enough to fix things.
> Is the existing Pipelines integration enough for you to turn it on for
> git/git, or do I need to tweak any settings?
All I need is to install the app:
Install GitGitGadget-Git
Install on your organization Git @git
All repositories
This applies to all current and future repositories.
Only select repositories
Selected 1 repository.
git/git
...with these permissions:
Read access to code
Read access to checks and metadata
Read and write access to issues and pull requests
... which I just did.
Thanks,
Dscho
next prev parent reply other threads:[~2019-11-22 13:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-09 2:00 Should we auto-close PRs on git/git? Emily Shaffer
2019-11-09 4:55 ` Junio C Hamano
2019-11-13 5:29 ` Stephen Smith
2019-11-12 19:11 ` Johannes Schindelin
2019-11-13 1:10 ` Jeff King
2019-11-13 12:04 ` Johannes Schindelin
2019-11-14 7:41 ` Jeff King
2019-11-14 23:03 ` Johannes Schindelin
2019-11-18 18:37 ` GitGitGadget on git/git, was " Johannes Schindelin
2019-11-21 10:54 ` Jeff King
2019-11-22 13:50 ` Johannes Schindelin [this message]
2019-11-22 14:43 ` Johannes Schindelin
2019-11-25 14:30 ` Jeff King
2019-11-26 20:55 ` Johannes Schindelin
2019-11-26 21:56 ` Eric Wong
2019-11-26 22:22 ` Johannes Schindelin
2019-11-26 22:40 ` Eric Wong
2019-11-26 22:52 ` Johannes Schindelin
2019-11-26 23:58 ` Eric Wong
2019-11-27 1:52 ` Junio C Hamano
2019-11-27 2:37 ` Eric Wong
2019-11-13 21:09 ` Emily Shaffer
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1911221430510.31080@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).