GDC CI

Iain Buclaw ibuclaw at gdcproject.org
Sat Sep 12 20:56:08 UTC 2020


On Friday, 11 September 2020 at 12:33:02 UTC, wjoe wrote:
> On Wednesday, 9 September 2020 at 23:13:38 UTC, Iain Buclaw 
> wrote:
>> On Wednesday, 9 September 2020 at 18:32:07 UTC, wjoe wrote:
>>> On Wednesday, 9 September 2020 at 12:37:37 UTC, wjoe wrote:
>>>> On Wednesday, 9 September 2020 at 12:13:32 UTC, kinke wrote:
>>>>> On Wednesday, 9 September 2020 at 11:33:22 UTC, wjoe wrote:
>>>>>> I suspect that maybe the compiler wasn't properly 
>>>>>> installed in the container ?
>>>>>
>>>>> Maybe just a typo in your Dockerfile? You're installing 
>>>>> `g++9`, but the package name is `g++-9`.
>>>>
>>>> Ahh good catch! It works now! Thanks :)
>>>
>>> The build as well as the unittests finished successfully.
>>> The entire run took close to 70  minutes. This was a linux 
>>> container with 4 CPUs and 10G RAM.
>>>
>>
>> Sounds about right.  There are a couple heavy modules that 
>> instantiate tens of thousands of functions when building 
>> phobos unittests.
>>
>>> Which files should be kept once the task completed and what 
>>> should happen with them ?
>>> On success I could add a package task.
>>>
>>
>> There's 'make install'.  I probably wouldn't prune anything 
>> copied during that recipe, as you'll lose integration with C, 
>> C++ and LTO compilers if any of those components are missing.
>
> I would create a prefix for make install, install to that 
> location, tar that folder and keep the tarball.
>

Yes, that works, IIRC the same was done for the historical binary 
tarballs.

> Also, on failure it would probably be a good idea to preserve 
> the logs ?
>

If stdout/stderr is accessible after build, then the relevant 
logs can just be cat'd.  For the testsuite, these be 
./gcc/testsuite/gdc/gdc.log and 
./x86_64-pc-linux-gnu/libphobos/testsuite/libphobos.sum 
(substitute the target where necessary).

> The docs mention that it's possible to define GitHub actions, 
> e.g. to email stuff. Would that be useful ?

In the event of failed builds, or builds where the success/fail 
status changed, perhaps.  Having emails for every build would 
just be noise.


More information about the D.gnu mailing list