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 <doev...@pivotal.io> 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 <rhough...@pivotal.io> > 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 <mario.iva...@est.tech> regarding exemptions to the Gradle task. >> >> I would like to have a [VOTE] by end of week on this. >>
