invalid at example.com
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
>> 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