On Thu, Feb 07, 2019 at 09:53:18PM -0500, Jeff King wrote:
> > > I'm happy to. I walked through the Azure setup/login procedure, but I'm
> > > not sure what to do next.
> >
> > The next step would be to install Azure Pipelines from the Marketplace and
> > activate it for git/git. There *should* b
On Thu, Feb 07, 2019 at 10:57:48PM +0100, Johannes Schindelin wrote:
> > Fair enough. As an alternative, do you know offhand if there's an easy
> > machine-readable way to get the CI results? If I could poll it with curl
> > and generate my own notifications, that would be fine for me.
>
> There
On Fri, Feb 08, 2019 at 01:58:52AM +0100, SZEDER Gábor wrote:
> On Thu, Feb 07, 2019 at 03:45:02PM -0500, Jeff King wrote:
> > Fair enough. As an alternative, do you know offhand if there's an easy
> > machine-readable way to get the CI results? If I could poll it with curl
> > and generate my own
On Thu, Feb 07, 2019 at 03:45:02PM -0500, Jeff King wrote:
> Fair enough. As an alternative, do you know offhand if there's an easy
> machine-readable way to get the CI results? If I could poll it with curl
> and generate my own notifications, that would be fine for me.
Well, what do you mean by "
Hi Peff,
On Thu, 7 Feb 2019, Jeff King wrote:
> On Thu, Feb 07, 2019 at 03:26:21PM +0100, Johannes Schindelin wrote:
>
> > > So IMHO this isn't really a show-stopper problem, so much as
> > > something that is a sign of the maturing test/CI setup (I say
> > > "maturing", not "mature", as it seem
Hi Peff,
On Thu, 7 Feb 2019, Jeff King wrote:
> On Thu, Feb 07, 2019 at 04:41:57PM +0100, Johannes Schindelin wrote:
>
> > > I think this can be limited to the tests that failed, which makes things
> > > much faster. I.e., we run the tests at the tip of topic X and see that
> > > t1234 fails. We
Hi Junio,
On Thu, 7 Feb 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Even when there are even only as much as 12 merge bases to test (which is
> > the current number of merge bases between `next` and `pu`),...
> > ...
> > And I sadly have to report that that's not the end of
On Thu, Feb 07, 2019 at 04:41:57PM +0100, Johannes Schindelin wrote:
> > I think this can be limited to the tests that failed, which makes things
> > much faster. I.e., we run the tests at the tip of topic X and see that
> > t1234 fails. We then go back to the fork point and we just need to run
>
On Thu, Feb 07, 2019 at 03:26:21PM +0100, Johannes Schindelin wrote:
> > So IMHO this isn't really a show-stopper problem, so much as something
> > that is a sign of the maturing test/CI setup (I say "maturing", not
> > "mature", as it seems we've probably still got a ways to go). As far as
> > no
Johannes Schindelin writes:
> Even when there are even only as much as 12 merge bases to test (which is
> the current number of merge bases between `next` and `pu`),...
> ...
> And I sadly have to report that that's not the end of it. Back when I
> implemented the automatic bisect after failed bu
Hi Peff,
On Wed, 6 Feb 2019, Jeff King wrote:
> On Tue, Feb 05, 2019 at 10:45:35AM -0800, Junio C Hamano wrote:
>
> > - Perhaps find the fork point, run tests to find known breakages
> >and exclude them? This would simply be not practical, as it
> >doubles the number of tests run, for
Hi Peff,
On Wed, 6 Feb 2019, Jeff King wrote:
> On Tue, Feb 05, 2019 at 11:34:54AM +0100, Johannes Schindelin wrote:
>
> > Peff, you asked at the Contributors' Summit for a way to get notified
> > when CI fails for your patch, and I was hesitant to add it (even if it
> > would be straight-forwar
On Tue, Feb 05, 2019 at 10:45:35AM -0800, Junio C Hamano wrote:
> - Perhaps find the fork point, run tests to find known breakages
>and exclude them? This would simply be not practical, as it
>doubles the number of tests run, for individual topic branches
>because there are an order
On Tue, Feb 05, 2019 at 11:34:54AM +0100, Johannes Schindelin wrote:
> Peff, you asked at the Contributors' Summit for a way to get notified when
> CI fails for your patch, and I was hesitant to add it (even if it would be
> straight-forward, really) because of the false positives.
>
> This is on
Johannes Schindelin writes:
>> For a topic like doc-diff that is primarily meant for developers and
>> documenters, it does not matter much, but for an old but important bug,
>> forking the topic to fix it at a point close to the origin is
>> crucial---that is what would allow people to merge the
Hi Junio,
On Tue, 5 Feb 2019, Junio C Hamano wrote:
> I am wondering if the automated testing can be made more useful by
> limiting the scope of testing if it is run on individual topic. For
> four primary integration branches, we do want to ensure all tests keep
> passing (or at least no tests
Johannes Schindelin writes:
> In particular, the tests t2024 and t5552 are broken for
> ma/doc-diff-usage-fix on Windows. The reason seems to be that those are
> already broken for the base commit that Junio picked:
> jk/diff-rendered-docs (actually, not the tip of it, but the commit fixed
> by M
Hi Peff and Martin,
On Tue, 5 Feb 2019, Jeff King wrote:
> On Mon, Feb 04, 2019 at 09:50:37PM +0100, Martin Ågren wrote:
>
> > `usage` tries to call $0, which might very well be "./doc-diff", so if
> > we `cd_to_toplevel` before calling `usage`, we'll end with an error to
> > the effect of "./do
On Mon, Feb 04, 2019 at 09:50:37PM +0100, Martin Ågren wrote:
> `usage` tries to call $0, which might very well be "./doc-diff", so if
> we `cd_to_toplevel` before calling `usage`, we'll end with an error to
> the effect of "./doc-diff: not found" rather than a friendly `doc-diff
> -h` output. Thi
`usage` tries to call $0, which might very well be "./doc-diff", so if
we `cd_to_toplevel` before calling `usage`, we'll end with an error to
the effect of "./doc-diff: not found" rather than a friendly `doc-diff
-h` output. This regressed in ad51743007 ("doc-diff: add --clean mode to
remove tempor
20 matches
Mail list logo
