<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 November 2017 at 15:31, Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Manuel M T Chakravarty <<a href="mailto:manuel.chakravarty@tweag.io">manuel.chakravarty@tweag.io</a>> writes:<br>
</span><span class="">> Why do we need the intermediate builds exactly? Wouldn’t they usually<br>
> fail? (When I do PRs with multiple commits, the state of the tree<br>
> between this commits will usually not be well-defined.)<br>
<br>
</span>No, every commit should build. This is in part a difference between<br>
Phabricator's patch-based model and GitHub's feature branch model.<br>
However, many projects using the latter also demand that all<br>
intermediate commits must be atomic, buildable changes. Sacrificing this<br>
property greatly complicates bisection.<br>
<br>
Building all intermediates is desireable as ultimately we would like to<br>
preserve per-commit build artifacts for the last few months of commits<br>
to enable easy bisection.<span class=""><br></span></blockquote><div><br></div><div>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? I thought we had decided (somewhere, I forget where) that we were going to require PRs to be squashed before pushing?</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> * I have tried enabling testing of Harbormaster Differentials via<br>
>>   CircleCI. Unfortunately it appears that CircleCI only supports<br>
>>   testing repositories hosted on GitHub. There are a few ways in which<br>
>>   we could proceed,<br>
>><br>
>>    a. Move ghc's staging area (the repository where Arcanist pushes<br>
>>       patches submitted with `arc diff`) to GitHub. This, however, would<br>
>>       require that we manually manage push privileges to this repository.<br>
><br>
> What do you mean by manually manage push privileges? In what way is<br>
> that not manually at the moment?<br>
<br>
</span>As long as a user had added a key to their Phabricator account pushing<br>
to the staging area will "just work". It requires no intervention from<br>
me. I believe in the event that we moved to GitHub I would need to<br>
manually grant users commit privileges to the staging area.<br>
<span class=""><br>
>>    b. Try to work around the issue by mirroring GHC's staging area to<br>
>>       GitHub and manually trigger CircleCI builds.<br>
><br>
> Is the manual triggering necessary, because Harbormaster would need to<br>
> wait until the repo is triggered (which it can’t)?<br>
<br>
</span>In general this whole mirroring situation doesn't appear to be a<br>
use-case that Phabricator's CircleCI integration supports. It demands<br>
that the staging area of the tested repository is hosted on GitHub.<br>
<span class=""><br>
>> * I have been honing the Hadrian test infrastructure; I'm currently<br>
>>   waiting on a build, but I expect this attempt will pass, at which point<br>
>>   I will merge it.<br>
><br>
> Great!<br>
<br>
</span>Sadly the build appears to reliably hang with no output. I'll need to<br>
look into this.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>______________________________<wbr>_________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>devops-group</a><br>
<br></blockquote></div><br></div></div>