If ApiChecker fails on your PR, and you merge anyway, it will fail on develop,
so there’s no question it should be a required PR check.
We left some checks optional to avoid blocking merges on unrelated flaky
failures. ApiChecker should never be flaky.
If/when Geode decides it’s time for a 2.0
Given that this job takes less than 10 minutes to run, pass or fail, I
don't see it adding any additional friction to the PR process in terms of
having to wait for things to finish. I am curious if there are any
circumstances we could envisage where skipping or bypassing this check
would be warrant
We have enabled this job on the develop and support 1.13 branches, and it
is going well. I would like this to be a blocking job for our pull
requests.
Are there any issues around this test that we want to address, or reasons
to *not* have it be a blocking job in the PR pipeline?
To seed the conve
I usually wait for that third +1 to show up. But since it's slow in coming,
I'll deliver it myself.
+1
Go for it, Robert.
On 5/12/20, 4:17 PM, "Donal Evans" wrote:
+1 Having parity between develop and support branches in terms of
checks/tests seems like a sensible idea.
On Tue, Ma
Thanks all.
On Wed, May 13, 2020 at 8:34 AM Joris Melchior wrote:
> +1
>
> From: Robert Houghton
> Sent: May 12, 2020 18:57
> To: dev@geode.apache.org ; Dave Barnes (Pivotal) <
> dbar...@pivotal.io>
> Subject: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.1
+1
From: Robert Houghton
Sent: May 12, 2020 18:57
To: dev@geode.apache.org ; Dave Barnes (Pivotal)
Subject: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13
This is a squash of GEODE-8083 and 8087, to bring the Java API comparison
jobs from Gradle and Conc
