Re: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13
+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 Concourse to the support branch. Currently runs cleanly from my terminal, and has been green on develop for a week or so. @Dave Barnes , as release manager, what say you?
Re: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13
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.13 > > This is a squash of GEODE-8083 and 8087, to bring the Java API comparison > jobs from Gradle and Concourse to the support branch. Currently runs > cleanly from my terminal, and has been green on develop for a week or so. > > @Dave Barnes , as release manager, what say you? >
Re: [PROPOSAL] Merge PR 5103 (GEODE-8083) to support/1.13
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, May 12, 2020 at 4:05 PM Owen Nichols wrote: > I see that ApiChecker PR Check < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F156385&data=02%7C01%7Cdaveba%40vmware.com%7Ccfaacff8634648109e4e08d7f6cab242%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249222753597209&sdata=Wn%2F%2B%2F7NP4rlxMT7w8HC%2BPqKoTIRysEx3p7RMupQ8dV4%3D&reserved=0> is passing for 1.13 > so it’s a +1 from me! > > > On May 12, 2020, at 3:57 PM, Robert Houghton > wrote: > > > > This is a squash of GEODE-8083 and 8087, to bring the Java API > comparison > > jobs from Gradle and Concourse to the support branch. Currently runs > > cleanly from my terminal, and has been green on develop for a week or so. > > > > @Dave Barnes , as release manager, what say you? > >
[DISCUSS] enable GitHub PR blocking on API breaking changes
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 conversation, there is an issue I am working on with @Mario Ivanac regarding exemptions to the Gradle task. I would like to have a [VOTE] by end of week on this.
Re: [DISCUSS] enable GitHub PR blocking on API breaking changes
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 warranted though, and what the procedure would be in those cases. For example, how would it handle the removal of a deprecated method from an API? It's not something that happens often, but it will happen eventually (I would hope). On Wed, May 13, 2020 at 2:32 PM Robert Houghton wrote: > 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 conversation, there is an issue I am working on with @Mario > Ivanac regarding exemptions to the Gradle task. > > I would like to have a [VOTE] by end of week on this. >
Re: [DISCUSS] enable GitHub PR blocking on API breaking changes
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 release, which would allow breaking backward compatibility, we should be able to provide a rule to allow that in the ApiChecker. > On May 13, 2020, at 3:49 PM, Donal Evans wrote: > > 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 warranted though, and what the procedure would be in those cases. > For example, how would it handle the removal of a deprecated method from an > API? It's not something that happens often, but it will happen eventually > (I would hope). > > On Wed, May 13, 2020 at 2:32 PM Robert Houghton > wrote: > >> 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 conversation, there is an issue I am working on with @Mario >> Ivanac regarding exemptions to the Gradle task. >> >> I would like to have a [VOTE] by end of week on this. >>
