<div dir="ltr">>  84% refers to our plan's container time allotment of 1500 hours<div><br></div><div>Even though Circle CI is using Google Cloud instances, the CI still imposes a time limit? But why?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 June 2018 at 19:13, 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">Hi everyone,<br>
<br>
Over the last few weeks while finalizing the 8.6 branch I've been<br>
working on cleaning up some loose ends on the CI front. This includes,<br>
<br>
 * Fixing the Fedora and Hadrian builds<br>
 * Whittling away at the i386 Linux failures<br>
 * Incorporating nightly slow validation (which is now green, thanks to<br>
   Alp's efforts)<br>
 * Incorporating Alp's fixes to Hadrian to get this build green again<br>
<br>
During this process, however, I have noticed that a concerning banner<br>
has appeared at the top of the CircleCI interface. It currently reads:<br>
<br>
   Your current usage represents 84% of your ghc Linux plan's limit.<br>
   Please upgrade in order to ensure no disruption in building.<br>
<br>
With the percentage gradually ticking upwards as builds finish. I<br>
believe 84% refers to our plan's container time allotment of 1500<br>
hours (confusingly mislabeled as "1500 minutes" on the website). So far<br>
in the current May 21 - Jun 21 billing period we have used 1250 hours of<br>
build time. This is concerning as it presumably means that when we<br>
eventually overrun our budget we will be left without any CI at all for<br>
the remainder of the month.<br>
<br>
Given that we are currently building only a subset of commits on only<br>
the `master` I'm rather concerned that we are within a stone's throw of<br>
this situation (perhaps even going over this month). This seems<br>
untenable, especially when we consider that the number of builds will<br>
soon be growing to include stable branch backports, patches under<br>
review, and release builds.<br>
<br>
To manage this it seems that we will likely need to draw from a few of<br>
the tools at our disposal:<br>
<br>
 a. Reduce the number of build configurations that we build every commit<br>
    in (e.g. Fedora and LLVM could likely be relegated to a nightly build)<br>
<br>
 b. Reduce the amount of parallelism that we allow CircleCI to employ:<br>
    having access to CI consistently throughout the month is far<br>
    preferable to faster build turnarounds for some of the month<br>
    followed by periods of no CI for the rest.<br>
<br>
 c. Increase the build time limit; this is $50/month/container<br>
<br>
In the short-run we can implement (a) immediately. This of course will<br>
reduce our coverage, but it looks like our coverage goals may not be<br>
practical given the resources we have. I've looked into (b) and haven't<br>
found any indication that CircleCI supports our use-case. If this is<br>
the case then we will have to simply pursue (c).<br>
<br>
I suppose <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a> may be able to contribute here. However, I wonder<br>
what other resources could be deployed.<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>