Transfer rules_scala to bazel-contrib

[meteorcloudy]

Description:

This issue proposes transferring the rules_scala repository from the bazelbuild GitHub organization to the bazel-contrib GitHub organization, which is owned by the Community for Bazel project under the Linux Foundation.

GitHub Discussion: https://github.com/orgs/bazelbuild/discussions/2

Impacts:

• GitHub issues & PRs will be transferred to the new repository.
• Branch protection rules will need to be transferred to the new repository.
• Individual maintainers will be transferred to the new repository.
• GitHub teams will NOT be transferred to the new repository and will need to be re-created.
• Bazel CI configurations will need to be updated to point to the new repository.

Read more on Transferring a repository from GitHub documentation.

Checklist:

• Obtain approval from the current project maintainers (@liucijus, @simuons).
• Obtain approval from the bazel-contrib SIG (@alexeagle).
• Initiate the transfer process on GitHub (@meteorcloudy).
• Update Bazel CI settings and confirm presubmit & postsubmit work (@meteorcloudy).

[alexeagle]

Notes from SIG meeting: this transfer was unanimously approved by a thumbs-up vote.

[simuons]

Approve. Thanks.

[liucijus]

👍🏻

[meteorcloudy]

Thanks for the approvals, I'll initiate the transfer now.

[meteorcloudy]

Just noticed rules_scala doesn't support Bzlmod yet, is that going to be a blocker? @alexeagle

See 9 from https://bazel-contrib.github.io/SIG-rules-authors/hosting-policy.html#adding-criteria

[alexeagle]

Yes, thank you - we ought to hold off on this one in that case.

Of course it's just as feasible to fix for bzlmod after the transfer, but I think the SIG would like to know who is committed to doing that work.

[meteorcloudy]

Agree, it's better to clarify that since we are disabling WORKSPACE in Bazel 8.

[meteorcloudy]

Essentially blocking on #1595

@liucijus @simuons Any plan to review and accept that PR?

[simuons]

@meteorcloudy I don't think that PR is complete. I'll be able to look at this next week.

[mbland]

BTW, I've just posted my willingness to contribute to Bzlmodification in #1482 (comment), if folks are cool with that. As stated there, I've a (mostly) working branch already.

[simuons]

Hi, @mbland, if you could take this that would be awesome. I promised to look at it a week ago but couldn't. So any help here would be greatly appreciated.

[mbland]

@simuons My pleasure! I'm very close to having the bzlmod branch in my fork passing ./test_all.sh. I'll be carving off other independent pieces shortly.

A question regarding Bazel 6 support: I'm making sure my changes are still compatible with Bazel 6 and WORKSPACE, but I've also got them working with the latest Bazel 7. I don't have a strong opinion, but I'm curious which of the following options sound good to you:

• Keep .bazelversion and .bazelci at 6.5.0, test Bazel 7 locally while developing.
• Bump .bazelversion and .bazelci to (currently) 7.3.2, test Bazel 6 locally while developing.
• Bump .bazelversion to 6.5.0 and add extra CI jobs for 7.3.2 (or vice versa).

[mbland]

FYI, a brief status update: #1482 (comment)

Basically, I'm very close to being done with my first draft, and anticipate sending more pull requests soon.

[meteorcloudy]

/cc @romanowski, @lukaszwawrzyk from VirtusLab, who are also very interested in helping rules_scala development.

[simuons]

Hi, @mbland, answering "regarding Bazel 6 support: ". I think we should use third option. Keep bazel 6 until bzlmod is supported. Once bzlmod is ready we will make bazel 6 release and switch to bazel 7. Does this sound good to you?