To see the status of the community build:
- Clone this repo.
- Run
sbt run
. This will open a console. - Run
clone
to clone all the projects under the/repos
dir. The list of the projects is in thesrc/main/scala/ecosystem/data/projects.scala
file. - Run
check
to get the status of the build.
All the commands are available under src/main/scala/ecosystem/executeCommand.scala
. Every command object's overridden toString
method shows what to type in the console to run the command.
So far, BuildCommand
s are unsupported for SBT projects.
- Each project consists of the origin and upstream branch.
- The syncing is done via rebases to maintain linear history.
- Each project has the capability to force the Scala version from the command line when working with its build tool.
- Sanity rules: the following is the desired state of each project:
- Main branch name is standardized.
- Dotty CI points to the latest commit.
- Even with upstream.
- Staging area clear, no unstaged changes.
- Commands are provided to help the user overview and address each of the sanity issues in a standardized way.
- Commands are simple and do not push to the repos.
(3) Why not just modify the build? This is only Mill-related since SBT has the capability in question. It is needed for easy integration with our CI and when testing locally against the Dotty snapshot version. If our branch is modified and doesn't track the upstream perfectly, this complicates syncing with upstream. If our branch tracks upstream perfectly, the sync is trivially done via first merging the upstream and then submitting the PR to upstream. If it doesn't track perfectly, we need to take care of removing and reintroducing the private changes before submitting the PR. Introducing the capability to specify an extra cross Scala version into the community mill projects is non-intrusive so seems to be an optimal solution.