50GB of caches in branches is still being created. This doesn't
eliminate them all but makes a decent dent. This stops the more useful
master branch cache being evicted.
It's just built in the nightly. On macOS in the CI it's built twice, once as bin and once as lib, with a total of 600seconds according to cargo-timings.
In each C++/Rust/etc. docs step, attempt to generate an artifact that
has the directory structure suitable for the website right away, so
docs/$lang.
That way, eliminate the combine-deploy step and move the 404.html and
index.html generation to the publish_artifacts step, eliminating the
need to clone the website repo and running the generator for each build
in the master branch.
1. Removed the cron job that ran autofix.ci every morning to warm the cache.
2. A new reusable 'build_and_test_reusable.yaml' can be used by both ci.yaml and nightly snapshots.
3. Reduce ci.yaml build_and_test to macos-14 rust stable, ubuntu 22.04 rust 1.88 and windows 2022 rust beta.
4. With the nightly run on the free CI macos-14 rust nightly, ubuntu 22.04 nightly and windows 2022 rust 1.18.
This PR does 3 things.
1. The iOS simulator which is only needed after the build was booted before the build.
It is so resource heavy it causes the build to take 20-30 minutes. The simulator is now
booted after the build and the build itself now only takes 5 minutes.
2. There are multiple versions of the same named simulator for the multiple versions of
Xcode. It seemed somehow the wrong simulator could be selected for booting/installing/etc.
We now get the UUID of simulator and use that to launch it. That seems to have made the
job work. But as it fails randomly we don't know for sure yet.
3. The simulator would then be killed by the clean up process as the end of the run and it took
~40 seconds. There is now a step that tells the simulator to shutdown and that only takes
~7 seconds.
FrontBoard is a system that detects what app are on an iOS device or
simulator so they can then be launched. It can be slow to detect a newly
installed app leading to a race condition in CI where the action tries
to launch a successfully installed app before it's been registered. It
fails to launch and the CI fails with it. Now loop for a few seconds
retrying to launch before failing after 30 seconds.
Instead of using 'sleep' the system now waits for the simulators to boot
using 'xcrun simctl bootstatus booted -b'
Also added a timeout so if the job fails it won't hang forever.
* Install gettext on MacOS instead of compiling from source
1. Removes the attempt to install Ninja as it's included in the github
runner macos-xx images.
2. Brew install gettext and sets the env so it can be used during
compilation. This makes no difference on cached runs, but speeds up
uncached and initial runs.
* No need to install gettext
Overnight github evicts nearly all the useful cache as it's over 10GB in
size. This job re-runs the last 'successful' run in master and
repopulates the cache ready for the start of the work day.
This uses cargo --timings to create an HTML report attached to the workflow showing all the different items in the job and how long they take to compile. For now this is only used on the build_and_test matrix.
No need to cache the docs run. It was creating a 2GB cache file which uses up 20% of the 10GB allotment we have. It could be reduced to 1GB, how it's not really needed as without a cache this job only takes around 20 mins and could be split up to complete even faster.
This adds an option so any job can opt out of using the cache. It defaults to using the cache so right now everything that was using the cache will continue to do so.
The second change is that as we are well over the 10GB cache limit. So we will no longer save the cache created in a PR branch. As only the master branch cache is shared this PR branch cache could only benefit subsequent runs of the same PR. If this turns out to slow PR's down it can be easily turned off later.
A previous PR removed the concurrency group from autofix.ci as it
conflicted with the one in ci.yaml.
A side effect of this is that a new PR won't cancel a previous versions
run until the autofix part had completed. This only takes a couple of
mins, but it's still keeping many runners busy on a task that should be
cancelled.
Previously they ran in parallel which meant any commit by autofix would
cancel the CI jobs. This ensures the CI only runs afterwards and is
helped by autofix now only taking ~2 mins to run.
It should make a small difference to the amount of free runners.
As the GH images are updated with new iOS SDKs, not all combinations of device and iOS versions are always available due to limited disk space. The latest iOS sdks seem now only installed for the latest 13-inch iPad.
