[GHC DevOps Group] CircleCI job accounting question

[Manuel M T Chakravarty]

> 23.11.2017 06:15 schrieb Ben Gamari <ben at well-typed.com>:
> Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> writes:
> 
>> On 22 November 2017 at 15:31, Ben Gamari <ben at well-typed.com> wrote:
>> 
>>> Manuel M T Chakravarty <manuel.chakravarty at tweag.io> writes:
>>>> Why do we need the intermediate builds exactly? Wouldn’t they usually
>>>> fail? (When I do PRs with multiple commits, the state of the tree
>>>> between this commits will usually not be well-defined.)
>>> 
>>> No, every commit should build. This is in part a difference between
>>> Phabricator's patch-based model and GitHub's feature branch model.
>>> However, many projects using the latter also demand that all
>>> intermediate commits must be atomic, buildable changes. Sacrificing this
>>> property greatly complicates bisection.
>>> 
>>> Building all intermediates is desireable as ultimately we would like to
>>> preserve per-commit build artifacts for the last few months of commits
>>> to enable easy bisection.
>>> 
>> 
>> I don't quite understand this. Yes building all commits is desirable, but
>> in the case of Phabricator each revision is going to be a single commit,
>> no? So why is this an issue? Or is it an issue only for github PRs?
> 
> The problem is that many contributors, including Simon PJ, Richard, and
> me, tend to push batches of work. For instance, when I land
> contributors' differentials I first apply a batch, then validate
> locally, and then push as a chunk. We can change this if necessary, but
> it will need to be via social convention which hasn't worked very well
> historically.

I would like to understand this issue (which prompts #14505) a bit better. Do we agree that, in an ideal world, nobody should ever push to master, and instead, all contributions start as PRs or differentials, which are merged after being reviewed, which crucial includes building them in CI? If that were the case, then we wouldn’t have the issue with needing to force CircleCI to build non-head commits, right?

If we agree that this is the ideal scenario, then what is preventing us from getting to that scenario? In particular, I don’t think you should need to validate contributor code manually on your boxes. The purpose of an automatic CI pipeline is exactly to avoid such manual steps.

I am sorry if any of these questions appear naive.

Cheers,
Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171211/3b1c24fc/attachment.html>