ci: add ci config to test 7 and 8 for bcr like setup

[aignas]

Run the examples that BCR uses as tests in a more similar way to BCR.

Unfortunately, this breaks the gazelle plugin on Windows due to #3416, so testing of
it is removed.

Work towards #3392

[aignas]

OK, getting late, but I think this is a good start.

@rickeylev, do you remember what kind of limitations we have for CI slots?

[rickeylev]

There's a limit on the number of jobs. I'm not sure if its hard or soft.

Looking at the recent BCR failure, i'm guess it is covering windows+bazel 8 while we're not

[rickeylev]

re: CI failures: I think we just need --windows_enable_symlinks, then it should be OK

[aignas]

I remember @meteorcloudy suggesting that we should avoid forcing users to set this flag, because it requires Windows admin permissions. If we need to add it, then the Windows support may not work properly. I think the interesting thing is that we need this flag because we are trying to use our binary in a sh_binary, so this requirement may be not related to rules_python requirements but to rules_shell requirements.

[rickeylev]

That's a good point and would explain what we see better. Yeah, the regular tests, which also show up as symlinks on disk (even without the enable symlinks flag), work fine

I tested all the 8.x.0 versions and they all have this same issue. Bazel 7 didn't.

[fmeum]

One of the failing runs tries to run bazel coverage on Windows with Bazel 7. That certainly isn't supported and if it worked before then only by chance. It may work in Bazel 9.

[aignas]

OK, I am wondering how we can fix the current build that is saying that we need to update C++ version, but I am not sure where this is handled.

[rickeylev]

--copt=-std=c++17 should do it.

IIRC, the PR that upgrades rules_cc and protobuf ran into this, too?

[rickeylev]

Is bumping deps required for rules_python? IIRC, BCR is happy (enough) with rules_python right now.

For the gazelle piece, yes, we had to bump its deps

[rickeylev]

Ah, I think I see. the rules_python module depends on the gazelle plugin (dev dep)

I'm going to try and decouple them.

[rickeylev]

This is almost passing. It's just gazelle+windows that is failing due to the treesitter compiling bug.

[aignas]

Haha:

[aignas]

What should we do?

• Attempt to fix the gazelle building here.
• Comment out the line testing this and move do this part of Migrate from smacker/go-tree-sitter to the official tree-sitter/go-tree-sitter #3416.

[rickeylev]

Lets comment out the line testing it.

[rickeylev]

Aha! We can use python format syntax for parameterized parts in the name attribute. e.g. name: {bazel}

[rickeylev]

fyi @dougthor42 -- we've had to remove testing for windows for gazelle

[dougthor42]

fyi @dougthor42 -- we've had to remove testing for windows for gazelle

ACK and SGTM. The tree sitter compilation issue is super annoying. Sadly I haven't had any more time to dive into it (and having to learn gcc args doesn't help!)

Please make sure to note in the changelog that gazelle windows ci is temporarily disabled and that gazelle windows support is questionable.

[rickeylev]

note in changelog

Done

[dougthor42]

Maybe add Ubuntu 2404 too? Or is it not available in our ci?

[dougthor42]

Add debian 12? 13 is already out also.

[aignas]

I see that usually people test a particular version of the OS and I'd like to leave this for some future PR.

Source: spot checked various modules on the bazel central registry a little.