[GHC DevOps Group] CircleCI job accounting question

[Manuel M T Chakravarty]

> Am 14.12.2017 um 01:36 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> On 12 December 2017 at 08:12, Manuel M T Chakravarty <manuel.chakravarty at tweag.io <mailto:manuel.chakravarty at tweag.io>> wrote:
> Hi Ben,
> 
>> Am 12.12.2017 um 02:22 schrieb Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>>:
>> 
>> Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> writes:
>> 
>>> The problem is that many contributors, including Simon PJ, Richard, and
>>> me, tend to push batches of work
>>> 
>>> I have not been following this thread (“job accounting” seemed above
>>> my pay grade) but I saw this mention of my name 😊. Without having
>>> read myself into the context there seem to be two issues
>>> 
>>> 
>>>  * Every commit to master should be validate-clean, and this should
>>>  be tested by the CI framework not by the contributor. This is
>>>  essential. I would be delighted if every commit I made went through
>>>  that gate. I’m careful, but occasionally not careful enough.
>>> 
>>>  * Most – perhaps all – commits should go through a code-review
>>>  process. Here I freely admit that I tend to use (or abuse?) my
>>>  status to make most of my commits without review, except perhaps
>>>  informally with individuals. I’d be absolutely willing to review
>>>  this if (a) in fact people think that the extra step would really
>>>  improve quality (perhaps looking at past commits) or (b) the very
>>>  fact that I do so makes people feel cross.
>>> 
>> I personally think that we should strive for your first point (every
>> commit should be validate-clean) before attempting to tackle your
>> second. I, for one, am rather skeptical that putting all of your patches
>> through review would significantly affect quality.
> 
> I completely agree.
> 
> So, what is preventing us from disabling direct pushes to master and requiring all contributions to go through a PR or Differential? 
> 
> Well, CI needs to be working first :)

CI itself is working for Linux and macOS, and the hold up with Windows is largely us trying to get it for free from AppVeyor. The outstanding problems are with getting Phabricator to integrate/cooperate and now agreeing on a workflow. If we would use GitHub and PRs (like most of the rest of the world), I think, all this would be solved already also. 

Custom infrastructure => extra costs, as usual.

> Also Phabricator doesn't have the equivalent of a merge button right now, which makes the workflow a bit awkward. I'm not sure what the current state of that is - is there an extension or something we can enable to get this, Ben?
> 
> PRs and Differentials are squashed on merging to master and the whole problem (with CircleCI building only heads of commit groups) just disappears. I believe that this is the usual approach.
> 
> How do we enforce that PRs get squashed on merging? (not that we’re actively using PRs (yet) but I’m curious how this works).

GitHub has a per-repository setting allowing a choice between three options as follows.

When merging pull requests, you can allow any combination of merge commits, squashing, or rebasing. At least one option must be enabled.
Allow merge commits 
Add all commits from the head branch to the base branch with a merge commit.
Allow squash merging 
Combine all commits from the head branch into a single commit in the base branch.
Allow rebase merging 
Add all commits from the head branch onto the base branch individually.


If more than one option is allowed, you can choose which one to use at the time of pressing the merge button.

Cheers,
Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171214/598fc9d9/attachment-0001.html>