Convert git checkout to dir in flatpak manifest since otherwise some git operation fails.
Set branch name to "ci" to avoid clashes with other installs.
It's better to disable them that to get in the habit of ignoring the CI fails
from the following two issues; this can be reverted once either is fixed.
glib has a bug where it builds things out of order which results in it failing
to build the dependencies, which fails the build.
https://github.com/microsoft/vcpkg/issues/28722
vcpkg also has a bug where it very often fails to use the cache of the
previously built dependencies even if none of them changed, which then makes it
rebuild all the dependencies again.
https://github.com/microsoft/vcpkg/issues/26601
If the glib bug was fixed, then the errors wouldn't happen since rebuilding the
dependencies wouldn't fail. If the caching bug was fixed, then the errors
wouldn't happen since it'd just reuse the cached dependencies.
The Windows CI builds are intermittently failing. Even though a prebuilt vcpkg
is already cached, it will sometimes choose to rebuild lots of packages anyway.
On some of those rebuilds, there's a failure when building glib.
On the times that it does fail, the failure is often enough glib that checking
the build log manually seems more reasonable than checking what failed.
An alternative would be to look at why it sometimes chooses to rebuild, but
that would mean remotely debugging a CMake config. I'm hoping the build log
will have a clear compiler error pointing to a race condition in the order that
packages are built.
Looking at recent build failures, one of Debug or Release is using the prebuilt
vcpkg from the cache, and the other one is detecting it but then deciding to
rebuild many of the packages.
The build logs circa 8bd8c53f98 are no longer
accessible, only the success/failure and time taken are still accessible.
Looking at build timings around those changes is inconclusive, however my guess
is that the CI is noticing that CFG is different between the two builds, and
that's forcing a rebuild for one of them.
The vital commit is fd766eba2b4cf59c7123d46189be373e2cee959d, but
I'm taking the most recent version of vcpkg as the new baseline
because it might as well use the latest.
The only suggestion that came up was checking to see if something in this file changed between when the vcpkg cache is used vs isn't used, so... print out the contents of a random dependency and then check back later I guess.
