scalacenter / bloop

Bloop is a build server and CLI tool to compile, test and run Scala fast from any editor or build tool.
https://scalacenter.github.io/bloop/
Apache License 2.0
907 stars 202 forks source link

Bloop is no able to detect custom source sets #1765

Open slovvik opened 2 years ago

slovvik commented 2 years ago

Given the following configuration:

lazy val SystemTest = config("system") extend(Test)

lazy val root = (project in file(".")).
configs(IntegrationTest, SystemTest)
  .settings(
    inConfig(SystemTest)(Defaults.testSettings),
    Defaults.itSettings,
    inThisBuild(List(
      organization := "com.example",
      scalaVersion := "2.13.6"
    )),
    name := "scalatest-example"
  )

libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % Test
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % IntegrationTest
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % SystemTest

and when running sbt bloopInstall the following files are generated:

[success] Generated .bloop/root.json
[success] Generated .bloop/root-test.json
[success] Generated .bloop/root-it.json

bloop projects also show only:

root
root-it
root-test

It looks like bloop is not able to detect the system-test source set.

dos65 commented 2 years ago

Thanks for reporting! Yep it doesn't support non build-in scopes.

I took a quick look so here a bit details:

bloopGenerate task is defined only for Compile, Test, IntegrationTest scopes: https://github.com/scalacenter/bloop/blob/c1fd321b3f62da4fab79b19794616990c7b656c8/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L226-L228

And bloopInstall filter scopes where this task is defined: https://github.com/scalacenter/bloop/blob/c1fd321b3f62da4fab79b19794616990c7b656c8/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L1109-L1114

Also, we can use this method imp from sbt-bsp as a reference: https://github.com/sbt/sbt/blob/1f29c9053cdc52128fa45cfe0b22e9a4d085cc1b/main/src/main/scala/sbt/internal/server/BuildServerProtocol.scala#L520

slovvik commented 2 years ago

@dos65 thank you for taking a look. Is it something that can be taken by someone? :) We are frustrated with using Intellij, but without this feature, we can't switch. For me, it will take like a whole eternity to do it :(

Arthurm1 commented 2 years ago

@slovvik I don't know much about SBT but can you use this document's suggestion as a workaround?

Adding addSbtPlugin("ch.epfl.scala" % "sbt-bloop" % "1.5.2") to project/plugins.sbt

and using something like...

import bloop.integrations.sbt.BloopDefaults

lazy val SystemTest = config("system") extend(Test)

lazy val root = (project in file(".")).
configs(IntegrationTest, SystemTest)
  .settings(
    inConfig(SystemTest)(Defaults.testSettings ++ BloopDefaults.configSettings),
    Defaults.itSettings,
    inThisBuild(List(
      organization := "com.example",
      scalaVersion := "2.13.6"
    )),
    name := "scalatest-example"
  )

libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % Test
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % IntegrationTest
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % SystemTest

Not sure if that's what you need (or even if that's the best way to alter the SBT build).

I note that any non Test or IntegrationTest config will be tagged as a library so your system config tests won't be recognised in Metals as runnable

Perhaps the default bloopInstall should include all configs and tag them as tests if they inherit from the test config 🤷

slovvik commented 2 years ago

@Arthurm1 it seems to do the trick but only in bloop. It has no support in the IDE, Metals in my case. It even broke current support for Test and IntegrationTest. Now I can't run them from the UI.

Perhaps the default bloopInstall should include all configs and tag them as tests if they inherit from the test config

I think so. Nowadays projects have all kinds of tests, so it would be cool to support them.

tgodzik commented 2 years ago

@dos65 looks like we could use the logic from BSP, but that would require someone with a much better knowldege of sbt than me :sweat_smile:

I think so. Nowadays projects have all kinds of tests, so it would be cool to support them.

Sure, the alternative would be having them under the same scope Test but in different modules if you need to split them. However, it would be good to support the different scopes.

dos65 commented 2 years ago

I will probably look at this issue a bit later. I dropped the notes because didn't want to switch on it immediately :smile:

francesconero commented 1 year ago

Hello, I was also interested in improving the test detection for custom configs. Digging through the code in the sbt integration I find that the tag selection logic is currently:

https://github.com/scalacenter/bloop/blob/3d9d78524a2e0044a176ae0c64e3f36291244d3a/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L880-L884

which, as already mentioned, doesn't take into account extended configurations.

Would changing it to something along these lines be enough?

val tags = List(
      depsFromConfig(configuration)
        .collectFirst {
          _.id match {
            case IntegrationTest.id => Tag.IntegrationTest
            case Test.id => Tag.Test
          }
        }
        .getOrElse(Tag.Library)
    )

I'm not sure about using the id of the configuration, but it would cover another (at least I think) common scenario where one simply does val myCustomIntegrationTest = IntegrationTest extend(Test). In that case going with a simple object equality comparison would only match the extended Test configuration, but I believe that to be a bit surprising, since the intention is probably just to slightly alter the default IntegrationTest behavior.