Closed xStrom closed 1 year ago
It does make sense and I wanted to do it, but you either have to manually update all the references (not that bad with search/replace) or reference a special variable that has to be defined by a repo admin in the github web UI. So I left it out of this PR at least.
As has been noted in #1 the
glazier
CI has been mostly a rough port of thedruid-shell
CI script. Recently, mostly thanks to @waywardmonkeys, our CI scripts have received some improvements. This PR here pushes that forward some more by incorporating somedruid-shell
post-fork changes and also a few other lessons from running the Druid CI over the years.Changes
CI
, instead of the automatic.github/workflows/ci.yml
to reduce UI noise.--workspace
which has no practical effect for Glazier at this point in time. The goal is to have a more easily syncable generic Linebender CI with minimal required changes per repository.Wayland no longer receives a separate job and instead gets tested using the general process.
The original reason why Wayland had its own job for
druid-shell
was because we had GTK, X11, and Wayland to test which meant that the Linux job ran significantly longer than others. With GTK gone that reason has withered. Now the counter argument to have a single Linux job is stronger. Most of the common dependencies are already built for X11 so the additional building needed for Wayland is small. Also this helps reduce the GitHub job cache eviction pressure by no longer saving ~430MB per Wayland test run of essentially duplicate artifacts.libx11-dev
&libpango1.0-dev
from the dependency setup. The former is preinstalled already, the latter is no longer required.windows-2019
towindows-latest
which currently translates towindows-2022
.Run
clippy
with no default features, then default features, then all features. This doesn't have too much of an impact on time spent, because the follow-up stages can reuse most dependencies that were built in an earlier stage.As for motivation, imagine a scenario where
glazier
depends onlib_a
and optionally onlib_b
. Glazier code usingfeat_a
oflib_a
works fine, becauselib_b
enableslib_a::feat_a
. However whenlib_b
is no longer included, code unexpectedly breaks. This has happened in practice with Druid and so doing more granular feature testing helps avoid it. Of course in a perfect world we would test every feature combination. However for regular CI I think starting with these three options should help catch most cases.clippy
errors early before they hit stable. Now that #76 is merged and the strategy is to explicitly update the toolchain version, there won't be any sudden breakage that these beta jobs were meant to combat. So we can just remove them.Fixes #1