Could we adopt some sort of merge-blocking hook that prohibits merge of PRs failing unit tests? My team has such an approach at work and it reduces the volume of breakage quite a bit. The only time we experience problems now is where our unit test coverage is poor, but we improve the coverage every time a breaking PR shows up. If our goal is to harden airflow for ongoing functionality with reduced breakage, this would be one good way to get there.
On Mon, Jun 11, 2018 at 7:55 PM Gerardo Curiel <[email protected]> wrote: > Hi folks, > > The master branch has been broken for a couple of days already. But that > hasn't stopped the project from merging pull requests. As time passes by, > it gets hard to identify what change caused the breakage. And of course, > fixing it might cause conflicts with the changes introduced by the merged > PRs. > > It seems to me that there should be some sort of process or guidelines in > place to avoid this sort of situations. "Don't merge if master is red" > seems like a reasonable option. > > If this guideline sounds obvious enough that it shouldn't be spelled out in > the commiters' documentation, then that's fine, but it hasn't been followed > recently. > > Cheers, > > -- > Gerardo Curiel // https://gerar.do >
