Minimize CI burden by commenting out parts of the matrix

[paddy-exe]

• Minimizes CI burden by commenting out parts of the matrix so that one entry for every platform remains

Before-After comparison

Before:

After:

• Adds a commented out option for web builds using threads=no

[Ivorforce]

I'm not sure I like disabling CI, it means users will have to re-enable these builds manually with a commit when cloning the repo.
Since most time spent is compiling godot-cpp, a more effective way to speed up CI would be to use a build profile. We could configure the profile from the repository variables, such that it is only in effect for the template repo, but not for cloned projects. What do you think?

Edit: Actually, I'd disable double builds by default (aka half of CI). I don't think many people are using that anyway.

[paddy-exe]

I'm not sure I like disabling CI, it means users will have to re-enable these builds manually with a commit when cloning the repo. Since most time spent is compiling godot-cpp, a more effective way to speed up CI would be to use a build profile. We could configure the profile from the repository variables, such that it is only in effect for the template repo, but not for cloned projects. What do you think?

Hmm yeah I guess you could be right. On the other hand probably not everyone would be wanting to have everything enabled by default anyways. Not every extension will (need to) work on every platform. Also one commit to enable everything doesn't sound very bad in my opinion. You will probably want to configure your stuff anyways since we have the naming predefined with the template variables. So might as well... I am not opposed to build profiles though. Haven't heard about them though (I only get weird search results). Do you mind sharing a link to a docs page?

Edit: Actually, I'd disable double builds by default (aka half of CI). I don't think many people are using that anyway.

Even better. So that would change the line

float-precision: [single, double]

to this here then?:

float-precision: [
single, 
#double
]

[Ivorforce]

I am not opposed to build profiles though. Haven't heard about them though (I only get weird search results). Do you mind sharing a link to a docs page?

I don't think they're documented yet :/

They're used to compile only parts of godot-cpp, and skip the rest. You can use one with the build_profile=some/path/to/build_profile.json command.
They look like this: https://github.com/Ivorforce/NumDot/blob/main/configure/build_profile.json

I think they need to be in a file, but as long as users don't manually use the build_profile command, they won't 'have to deal' with most classes mysteriously missing when they first test it out.

Edit: I just remembered, we do actually have a dummy build_profile.json in this repository.

Even better. So that would change the line

float-precision: [single, double]

to this here then?:

float-precision: [
single, 
#double
]

Yep, that should work!

[Bromeon]

You can use include: to add individual matrix combinations, without running into combinatorial explosion. This would allow double builds to still be tested, just not for all other dimensions.

We follow a similar approach in godot-rust. We run 3 double jobs in total, one per Desktop platform.

[paddy-exe]

@Bromeon You mean like this? I took a look at gdext and the docs page you linked

[Bromeon]

Yes, does it work as expected?

Small side note, the [ ] syntax across multiple lines is a bit unusual in YAML, although allowed. Typically lists are - prefixed like here 🙂

[paddy-exe]

Not really sure :/ the action on GitHub doesn't run (and doesn't show any debug info either). I tried to run the action locally but I can't run everything there with Docker either 😅

[Bromeon]

It's here, in the Actions tab of the repo 🙂

Build GDExtension
Error when evaluating 'runs-on' for job 'build'. .github/workflows/builds.yml (Line: 54, Col: 14): Unexpected value ''

The problem is that target is nested (itself a list of objects containing platform/arch/os), but you only refer to its sub-keys.

The include however needs to refer to paths from the top level, like target-type. I'm not sure how the exact syntax would work for a nested property, maybe

    include:
      - target:
            platform: linux
            arch: x86_64
            os: ubuntu-22.04
        float-precision: double

GitHub Actions are always trial&error, you might need to experiment a bit (or ask an AI, which itself can be trial&error) 😬 But it's also possible that this isn't supported, and would need flat keys.

[Ivorforce]

Personally, I use the GH runners to make builds, and I trigger CI manually only once every month or so. So I'd definitely prefer CI that has all the templates enabled by default, and with a nice and clean configuration — but also have it not auto-run on push.
But in this repository, it's set to run by default. I suppose with that configuration, it makes sense to only check a few combinations.

So yea, even though I personally don't like the change much, i guess it's a net plus in most situations.
We should probably still be making that build profiles change though, at least here. That should save us another ~80% or so of build time. But I'm happy to do that as follow-up.