wjoe invalid at
Wed Sep 16 23:06:47 UTC 2020

On Wednesday, 16 September 2020 at 21:25:19 UTC, Iain Buclaw 
> On Wednesday, 16 September 2020 at 10:47:01 UTC, wjoe wrote:
>> On Wednesday, 16 September 2020 at 10:23:16 UTC, Iain Buclaw 
>> wrote:
>>> [...]
>> Configuration wise that's not a problem at all. My reasoning 
>> for the dependency was that there's no point in making a 
>> release tar ball if the Unittests task fails.
> It's not really the end of the world if a test fails.  While 
> tagged releases should ideally all pass, some failures can 
> occur that are not our fault (i.e: x32 has a libc bug that 
> causes some syscalls to fail and trigger asserts in a couple 
> libphobos tests).
> For non-tagged builds, I imagine we'd just be replacing the 
> previously built tarball based on the given branch it was built 
> off, so if something really is broken, in the worst case we 
> just wait until a fix goes in and retrigger CI.  Or if some 
> downstream is affected, we'd have some sort of versioning in 
> place (such as syncthing) to do a quick restore.

I see. So I'll just remove the dependency and let all the tasks 
run in parallel. It may still be delayed due to scheduling but 
time wise it won't be worse that with a dependency on Unittest.

More information about the D.gnu mailing list