failing CI

[andrewrk]

The CI has been especially unreliable lately. Apologies to everyone who has been opening pull requests and seen false negatives.

I'm in the process of acquiring our own hardware to run the CI stuff on, to increase reliability and make it easier to troubleshoot when a flaky test failure happens.

It's going to be annoying for another week or so and then hopefully we will have something sorted out.

Thanks for understanding, I know it's been really annoying lately for everyone.

[andrewrk]

Update on the situation: ZSF now has a beefy Hetzner machine that we are paying 100 euros/month for, and @mikdusan has volunteered to work on migrating our CI infrastructure to it piecemeal. Thanks for being patient with us- taking more control over our CI pipeline is long, long overdue and this should bring long-term stability to the project.

This also opens up the opportunity to run performance-tracking benchmarks on every CI run as well.

[andrewrk]

Update: CI is getting closer to ready. Meanwhile, I rebooted the gotta-go-fast repository and added some zig ast-check benchmarks. Have a look at the README to see the new description of how it works now. The next steps will be:

• Backfilling some performance measurements
• Adding html/javascript to ziglang.org/perf which download the data and display interactive graphs
• Integrating with the new CI system so that performance measurements happen with every commit, and the data is synced to ziglang.org/perf with every commit

[andrewrk]

we have our first self-hosted CI run

[andrewrk]

x86_64 Linux has now been moved over to ci.ziglang.org. This should already improve stability of the CI and we are still planning on moving more over.

Meanwhile, https://ziglang.org/perf is live. Adjustments are still being made to integrate the page with the rest of the website as well as to the graphs.

[RossSmyth]

Having a Zig Bors/Homu may be a good idea so that all PR's are tested as the head of master before merging.

[matu3ba]

@RossSmyth The Azure build jobs on Windows are (yet) too unstable to do that unless Windows is excluded, lol. For example 10172 10168 10161 10151 all failed due to Windows timing out after 6 hours.

[andrewrk]

This particular issue is resolved. We have moved some things over to our self-hosted CI, reduced memory usage, and disabled flaky tests, and now CI is in an OK state.

[andrewrk]

Reopening - I'm seeing the aarch64 drone CI failing due to timeouts sometimes.

[andrewrk]

Solved in b095aa6