You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as it turns out, while we were also failing to catch all errors thrown from SSGC (fixed in 96ac866), the root cause of the build failure was a typical OOM.
May 16 22:43:06 u1.swiftinit.org systemd[1]: Started swiftinit.org builder.
May 16 22:54:53 u1.swiftinit.org systemd[1]: unidoc.service: A process of this unit has been killed by the OOM killer.
May 16 22:54:56 u1.swiftinit.org systemd[1]: unidoc.service: Failed with result 'oom-kill'.
May 16 22:54:56 u1.swiftinit.org systemd[1]: unidoc.service: Consumed 10min 35.212s CPU time.
May 16 22:54:56 u1.swiftinit.org systemd[1]: unidoc.service: Scheduled restart job, restart counter is at 1.
May 16 22:54:56 u1.swiftinit.org systemd[1]: Stopped swiftinit.org builder.
May 16 22:54:56 u1.swiftinit.org systemd[1]: unidoc.service: Consumed 10min 35.212s CPU time.
May 16 22:54:57 u1.swiftinit.org systemd[1]: Started swiftinit.org builder.
we can’t (economically) fix this, as we are currently using the AWS t4g.small promotion.
however, the builder really ought to be able to report its status when it is restarted, instead of us having to timeout the builds on the server side.
it seems the build, including the documentation build succeeds, but the builder fails to report its status for some reason
The text was updated successfully, but these errors were encountered: