[GHC DevOps Group] CircleCI job accounting question
Simon Marlow
marlowsd at gmail.com
Thu Nov 23 09:33:41 UTC 2017
On 22 November 2017 at 19:15, Ben Gamari <ben at well-typed.com> wrote:
> Simon Marlow <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.
>
Ah, I see, I thought the problem was just to do with branches. Thanks for
the clarification.
> I thought we had decided (somewhere, I forget where) that we were going to
> > require PRs to be squashed before pushing?
> >
> Please correct me if I'm forgetting something but I do not believe we
> have even decided that we would start accepting PRs for larger patches.
> I had said during ICFP that I was open to the idea, but experience
> with GitHub's reviewing tools has since led me to view the proposal with
> a bit more skepticism. Since this was prior to the creation of this
> mailing list I summarised these concerns in a private email to Manuel; I
> will forward this message to the list in a moment.
>
Right, we certainly haven't decided to move code reviewing to GitHub (and I
also have deep concerns about that). I was thinking about the case where
someone submits a PR via GitHub and we convert it into a Phabricator diff,
squashing in the process, or if the PR doesn't require reviewing then we
squash before pushing.
Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171123/20603f1c/attachment.html>
More information about the Ghc-devops-group
mailing list