The Community Build contains tests to build and test a corpus of open sources Scala projects against the latest version of Scala 3.
To run the community build on a local machine, first fetch all the git submodules with
git submodule update --init and run
sbt community-build/test from the root of the dotty repo.
To run a single project, you can use the usual syntax for running a single JUnit test, for example
community-build/testOnly -- *shapeless
In CI the community build is split up into 3 separate groups: A, B, and C. To run one specific build you can also use the same JUnit syntax as above targeting the individual group. For example:
sbt "community-build/testOnly dotty.communitybuild.CommunityBuildTestA"
The community build is able to handle both Mill and sbt projects. To add your project to the community build you can follow these steps:
Ensure your project is compiling with Scala 3. If you need help make sure to check out the Scala 3 Migration Guide. You can see the submodules in community-projects for examples of projects that compile with Scala 3.
Open a PR against this repo that:
Once the CI is green, someone from the Dotty team will fork your repo and add it to dotty-staging. This enables us to make changes to your fork if necessary to keep the community build running smoothly.
Once the fork is created, please update your PR to point to this new fork instead of your repo.
The projects included in the community build are all forked and located in dotty-staging. When something needs to be bumped the process is as follows:
Fork the dotty staging repo and sync it with the upstream project.
Once you've verified that the tests are all passing you can then either request in your PR that the dotty-staging fork be synced or in the scala-contributors discord channel.
- If you're unfamiliar with Git Submodules you can find a nice guide to get familiar with them here.
- Keep in mind that many projects are interrelated. So when you bump one that change may cascade through multiple different projects causing you to have to bump multiple. Plan accordingly and at times it's best to pin it to a stable release version, especially if it's a root library that many others in the community build are relying on.
You can find this here.