+1 for merge blocking hooks. It would be great to have safety knowing that any commit I revert to will still pass tests (for rebase testing, etc)
On Mon, Jun 11, 2018 at 10:23 PM Alex Tronchin-James 949-412-7220 <(949)%20412-7220> <[email protected]> wrote: > 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 > > >
