Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce tlCrossRootProject #43

Merged
merged 17 commits into from
Jan 7, 2022

Conversation

armanbilge
Copy link
Member

Fixes #34.

This introduces a tlCrossRootProject helper for creating the "root" aggregate project. It:

  1. Generates root, rootJVM, rootJS, and rootNative projects (all set to no-publish)
  2. Automatically sorts any aggregated projects and cross-projects into their appropriate roots (root itself collects everything)
  3. Adds an axis to the CI matrix for platform, but only adds jobs for platforms which are represented in the build

I've demonstrated/tested tlCrossRootProject on this build, where it adds a single ciJVM job to the matrix since there are no JS or native project in this build. (Note that we now also have a rootJS and rootNative project that are empty, just a small nuisance I hope.)

Comment on lines +18 to +30
lazy val root = tlCrossRootProject.aggregate(
kernel,
noPublish,
settings,
github,
versioning,
mima,
sonatype,
ciSigning,
sonatypeCiRelease,
ci,
core,
ciRelease)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here it is in action. Nothing fancy. Regardless of the name of the val it's assigned to, it always generates projects called root—I didn't want to fuss with macros.

ci/build.sbt Outdated
Comment on lines 3 to 4
addSbtPlugin("org.scala-js" % "sbt-scalajs" % "1.0.0") // scala-steward:off
addSbtPlugin("org.scala-native" % "sbt-scala-native" % "0.4.0") // scala-steward:off
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the CI plugin is trying not to be too prescriptive, and we don't use the JS/native plugins except to check for their presence on a project, these versions should be sufficient.

Hopefully this won't interfere with our other updates.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the Native plugin have have the non-breaking track record of Scala.js? What is the risk of this dependency to all the people who don't aspire to support Native, which I think is still most Typelevel projects?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All fair points, I'm not familiar enough with native but it's still much more in development. In any case, I ended up removing it because my plugin detection idea wasn't working. See #43 (comment).


private def aggregateImpl(projects: Project*): CrossRootProject = {

val jsProjects = projects.filter(p => Plugins.satisfied(p.plugins, Set(ScalaJSPlugin)))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, these filters don't work like I expected wanted them to—Plugins.satisfied is too strict.

@armanbilge armanbilge marked this pull request as draft January 4, 2022 04:23
Comment on lines +71 to +76
val jsProjects =
projects.filter(_.plugins.toString.contains("org.scalajs.sbtplugin.ScalaJSPlugin"))

val nativeProjects =
projects.filter(
_.plugins.toString.contains("scala.scalanative.sbtplugin.ScalaNativePlugin"))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too horrible?

@armanbilge armanbilge marked this pull request as ready for review January 4, 2022 04:35
Copy link
Member

@rossabaker rossabaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to minimize how much users need to think about cross-platform, but I'm worried that extra dependenare going to make it hard for the typical project that just wants an easy way to publish for the JVM.

ci/build.sbt Outdated
Comment on lines 3 to 4
addSbtPlugin("org.scala-js" % "sbt-scalajs" % "1.0.0") // scala-steward:off
addSbtPlugin("org.scala-native" % "sbt-scala-native" % "0.4.0") // scala-steward:off
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the Native plugin have have the non-breaking track record of Scala.js? What is the risk of this dependency to all the people who don't aspire to support Native, which I think is still most Typelevel projects?

@armanbilge
Copy link
Member Author

Yeah, that's a fair point. I agree we should leave dependencies to native out, but SJS I think is stable enough?

Alternatively, all of this could be moved to separate plugins actually: sbt-typelevel-ci-cross for tlCrossRootProject and one more super-plugin sbt-typelevel-cross on top of sbt-typelevel.

@rossabaker
Copy link
Member

I fear heading for 2^n plugins for n supported use cases. What is the approximate burden on a JVM-only project if the Scala.js machinery is present?

@armanbilge
Copy link
Member Author

armanbilge commented Jan 4, 2022

Just the Scala.js plugin on the sbt classpath. They can ignore this tlCrossRootProject thing, it's completely opt-in.

Edit: oh, I also put sbt-crossproject on the sbt classpath (this is another stable one I think). But this is not really necessary: I just added it as part of the catch-all superplugin.

Seq(GlobalScope / onLoad ~= { (f: State => State) =>
f andThen { s: State =>
BasicCommands.addAlias(BasicCommands.removeAlias(s, name), name, contents)
}
})

implicit def tlCommandOps(commands: List[String]): TlCommandOps = new TlCommandOps(commands)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know implicits aren't the most popular. Thoughts on this mkCommand syntax to help define the aliases?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this one does enough to justify the magic. If we frequently stubbed our toe quoting semi-colons, maybe, but we don't, and the helper doesn't fix that anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, I'll scrap it.

@armanbilge
Copy link
Member Author

These latest changes try to DRY the command alias stuff, since we end up with many more of these to handle ciJVM, ciJS, etc.

Copy link
Member

@rossabaker rossabaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to try this on an application, where cross-platform doesn't tend to be needed, and make sure that none of this interferes. But it seems reasonable.

@armanbilge
Copy link
Member Author

Agree on testing 👍

If I've done it right, it shouldn't interfere because the TypelevelCiCrossPlugin and TypelevelCi{JS,JVM,Native}Plugin are all so-called noTrigger plugins, i.e. they will only be activated if enabled explicitly. And that only happens if a tlCrossRootProject is created. Otherwise, everything here should sit dormant.

@armanbilge armanbilge merged commit 72a0452 into typelevel:main Jan 7, 2022
@armanbilge
Copy link
Member Author

This PR solved sbt/sbt-github-actions#3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support CI matrices split across JVM/JS
2 participants