This adds the third_party/ directory to the list of paths that will
trigger a CI workflow when changed.
Not all updates to third-party dependencies will necessarily change
code, but we bump dependencies infrequently so there's not much of a
problem with triggering CI on every change to third_party/.
This makes it so that the main CI workflow will only trigger if a change
is made to a code file in desktop_version/ (as the CI is only for
desktop_version/), or if the CI file itself is changed.
The CI workflow for Android will only trigger if Android-specific code
_could have_ changed. This includes all code that is definitely
Android-specific (e.g. Java files), but also C/C++ files that have
__ANDROID__ ifdefs.
Unfortunately, it's not possible to reuse the same list of paths across
two different event trigger types[1]. So we have to copy-paste here.
[1]: https://github.com/orgs/community/discussions/37645
This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines,
which cleans up the code a lot, and they weren't really needed anyways.
This commit also disables the editor on the Steam Deck, and adds a
program argument to re-enable the editor, `-enable-editor`.
> CMake is re-running because D:/a/VVVVVV/VVVVVV/desktop_version
> /build_default/CMakeFiles/generate.stamp is out-of-date.
> the file 'D:/a/VVVVVV/VVVVVV/desktop_version/CMakeLists.txt'
> is newer than 'D:/a/VVVVVV/VVVVVV/desktop_version/build_default
> /CMakeFiles/generate.stamp.depend'
> result='-1'
"newer" probably means "the last edit date is newer because it was just
cloned", so let's see if including it in the cache means the last edit
date will be kept the same too... We can freely do this, as the cache
key includes the hash of the file itself.
Since the initial `cmake -G "Visual Studio 17 2022" ..` seems to be a
real bottleneck on the Windows CI (sometimes taking multiple minutes
for seemingly no reason), cache the build folder based on the hash
of CMakeLists.txt. It should be possible to reuse the build folder if
CMakeLists hasn't changed, and if it does change (because someone adds
a source file or library or something), we'll just do that initial
cmake with -G once, and cache that version as well.
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
For some reason, this test takes a dozen seconds or more. Maybe because
it needs to boot up powershell or something like that? No idea, but
it's just sitting there. The cache action has a return value that
indicates whether there was a cache hit, so there's no need to use
Test-Path, saving CI time.
EDIT: Maybe the SDL cache hasn't ever been working. It seems to cache
30 bytes (huh?) and the folder it caches is C:\SDL, not C:\SDL2-2.24.0
as the folder would look like. So it was probably downloading SDL every
time anyway?
Also, I upgraded the cache@v2 action to cache@v3. I added a cache@v3
myself and noticed this was still using cache@v2, so I figured, why not
future-proof it? And that's when I notice this warning: "Node.js 12
actions are deprecated. Please update the following actions to use
Node.js 16: actions/cache@v2." So it's pretty good timing.
I missed this because to check for all instances of 2.0.22, I did `rg -F
'2.0.22'`. But ripgrep doesn't search in hidden directories by default,
so the actual command to run is `rg -F. '2.0.22'`.
This updates all references to SDL 2.0.22 to SDL 2.24.0, including the
Docker container that I maintain for Linux CI.
Be warned, this release of SDL updates the versioning scheme to be less
dumb. The previous version is 2.0.22, this release is 2.24.0 (so the
last number can be properly used for patch-level version releases).
2.0.22 just released 40 minutes ago.
This also updates the `Dockerfile` to use the URL from the GitHub
releases page, instead of SDL's servers.
I've also pushed a new Docker container to
`ghcr.io/infoteddy/vvvvvv-build`.
This replaces vcpkg with simply downloading the pre-compiled
dependencies from official upstream releases. The rationale is that
vcpkg is sometimes really slow to update to the latest SDL version when
it releases, and also that it requires the runner to compile SDL every
single time it's instantiated, which is slow and wasteful.
Instead, download the pre-compiled binaries of SDL from its release page
on GitHub. This way, we don't have to compile it ourselves, and we
aren't waiting on vcpkg whenever SDL releases a new version. And for
good measure, cache it so we aren't downloading it _every_ time, which
is even more efficient.
The same can't be done for SDL_mixer, though, because it doesn't have a
GitHub release page with pre-compiled binaries. Instead, we'll download
them from libsdl.org, which is an infrastructure that takes more strain
than if we used GitHub instead. But, it shouldn't matter anyways,
because we cahe this too. And we are going to ditch SDL_mixer for FAudio
in 2.4 anyways, so it's a moot point either way.
I have just built a new CentOS container based off of the updated
Dockerfile, which now has SDL 2.0.16 installed. This updates the CI to
point to the new container.
CI builds were added to this repository on the first day it was
released, and haven't really been touched since then. And since then,
2.3 has added NO_CUSTOM_LEVELS, NO_EDITOR, and OFFICIAL_BUILD builds to
the CMake file.
On top of the MAKEANDPLAY define already existing, this means CI
coverage is a bit sparse - covering compile failures for changes made to
most of the codebase, except for Steam and GOG, and not covering compile
failures if certain parts of the code get stripped out. And people do
forget to check for those configurations as well.
These mess of configurations is kind of a wake-up call to refactor and
generalize the code a bit, because we would probably be able to get rid
of at least two of these (Make & Play, and no-custom-levels) by making
it so custom levels behave indistinguishably from the main game. But,
that's something to do in 2.4. At the very least, we should cover these
in CI right now.
On a small note, I had to add a MAKEANDPLAY configure option to the
CMake file to be able to easily configure a Make & Play build from the
CI runner. This option shouldn't really be used otherwise, so I added a
note to it telling people to consider modifying MakeAndPlay.h instead.
