[GHC DevOps Group] CircleCI job accounting question

[Ben Gamari]

Manuel M T Chakravarty <manuel.chakravarty at tweag.io> writes:

>> Am 13.12.2017 um 02:54 schrieb Ben Gamari <ben at well-typed.com>:
>> 
>> Admittedly this is where a Git-based workflows have a bit of an
>> advantage: it is much more convenient to merge a group of commits in a
>> structure-preserving manner via a git branch than a stack of
>> differentials.
>
> Sorry for being unclear, but I was not suggesting to put Simon’s
> commits in Differentials to review them, but to make everything go
> through the same funnel, triggering CI on all the commits it ought to
> be triggered on.
>
> Generally, I think, direct commits to master are bad process (and this
> why this is not well supported by CircleCI either). Two key points of
> CI are

Yes, I completely agree. I would also to eliminate the need to push
directly to master. Some time ago I had a slightly different scheme in
mind for which I developed [1] a bit of automation in the course of
another project. Namely, you stand up a simple daemon which tests
commits pushed to a magic branch. The daemon simply fires off a CI job and when
it finishes, it pushes the commit to master. This is somewhat similar to
the technique used by Bors but without the GitHub dependency. I had
intended to set this up for GHC when the Jenkins work had concluded.


[1] https://github.com/bgamari/auto-push

[snip]

> The hold up seems to be that Phabricator creates an overhead, which
> has prompted the use of the loophole (= direct push to master).
>
> How about the following solution? Everything that is directly pushed
> to master currently, is being pushed to GitHub and goes through a PR.
>
> After all, the main criticism of GitHub PRs seems to be about code
> reviews being nicer on Phabricator and we don’t want code review on
> the direct pushes to master anyway. So, why not use GitHub for this?
>
Historically GHC avoided this since GHC avoided merge commits as they
complicate bisection. However, now since GitHub supports rebase-merging
this is certainly a compelling option. It's certainly much simpler than
the approach I outlined above yet provides the same benefits.

If no one objects I think this sounds like a great path forward.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171214/f682c299/attachment.sig>