[GHC DevOps Group] CircleCI job accounting question

[Boespflug, Mathieu]

> 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).

It's the gatekeeper (i.e. Ben) that presses the merge button. And it can be
set to squash merge by default.

--
Mathieu Boespflug
Founder at http://tweag.io.

On 13 December 2017 at 15:36, Simon Marlow <marlowsd at gmail.com> wrote:

> On 12 December 2017 at 08:12, Manuel M T Chakravarty <
> manuel.chakravarty at tweag.io> wrote:
>
>> Hi Ben,
>>
>> Am 12.12.2017 um 02:22 schrieb Ben Gamari <ben at well-typed.com>:
>>
>> Simon Peyton Jones <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 :)
>
> 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).
>
> Cheers
> Simon
>
>
> If the outstanding issue is that you combine multiple contributions from
>> contributors and manually valid them to ensure they are not just
>> individually sound, but also in combination, we might want to consider
>>
>>   https://bors.tech
>>
>> which is exactly for that kind of thing (and apparently used by Rust).
>>
>> Cheers,
>> Manuel
>>
>>
>> _______________________________________________
>> Ghc-devops-group mailing list
>> Ghc-devops-group at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>>
>>
>
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171213/542c77b1/attachment.html>