[It still doesn't
work.](https://github.com/ppy/osu/actions/runs/22759488243/job/66012293202)
Looking at the [job
output](https://github.com/ppy/osu/actions/runs/22759488243/job/66012293202#step:1:21)
it appears that the permissions of the `GITHUB_TOKEN` are
*automatically* constrained to `read` even if you request more scopes.
Would be nice if that was *actually documented* somewhere!
Also given supply-chain attacks that people are running on github [via
*issue titles* these
days](https://grith.ai/blog/clinejection-when-your-ai-tool-installs-another)
I'm not sure we want any automation near where it can reach code. Sure,
much of the fault in the aforementioned attack was the fault of meatbags
trusting clankers *WAY* too much, which is a mistake we *would not* do,
but given everpresent software degradation *from unknown sources and for
unknown reasons* let's not ~~COPILOT~~ *ahem* tempt fate...
Another month, another freak android build failure.
From what I can tell, this time the build is broken because the second-
-to-last workaround applied to fix it, namely explicitly specifying
the version of workloads to install, stopped working, presumably because
github pushed a new .NET SDK version to runners, and microsoft didn't
actually put up a set of workload packages whose version matches the
.NET SDK version 1:1.
Thankfully, the fix to the *last* android build breakage (which caused
the workload installation to completely and irrecoverably fail), appears
to be rolling out this week, and *also* fix that same second-last issue,
so both workarounds of specifying the workload version and pinning the
image to `windows-2019` appear to no longer be required.
Note that the newest image version, 20250209.1.0, is still not fully
rolled out yet, thus rather than just fix all builds, this will fix like
20% of builds until the newest image is fully rolled out. But I guess
a 20% passing build is better than a 0% passing build, in a sense...?
In https://github.com/ppy/osu/actions/runs/11311858931/job/31458581002, I cancelled the run during the download from `data.ppy.sh`.
In https://github.com/ppy/osu/actions/runs/11313128285/job/31461534857, `wget` skipped downloading the file due to the `-nc` option (no-clobber), i.e.: if the file exists, don't re-download.
The only way I'm aware of to resolve this with wget is to either use `-c` (continue), which may lead to broken files, or to explicitly specify the output file via `-O`. Thought I'd clean up a few pieces in the process.
Why not curl? Mostly historical - some distros don't come with curl. It may be okay now but there's probably no point changing this at the moment...