On Wednesday, 16 September 2020 at 21:25:19 UTC, Iain Buclaw
wrote:
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.
