Creating native-package for tests

[mdedetrich]

This is more of a feature request than a bug report. I have an interesting problem at work where I need to create a package but for my tests rather than my application, so idea would be rather than doing universal:packageBin you would do test:packageBin or test:universal:packageBin.

Ideally it would replicate everything the same way the tests would work, including with parent/sub projects, i.e. by default running test on a parent project would also run tests for all of the sub projects.

I also assume that you need to put the sbt test runner into the package or something along those lines?

[muuki88]

Hi @mdedetrich and thanks for the feature request 😊

I had a similar requirement at my company. We wanted to run the integration tests and regression tests for downstream services. We didn't use native packager back then, but the idea is the same.

You put your tests in a submodule and everything in compile and not test scope. Then you'll get an executable for your tests.

Having that said . We replaced this with simple git checkouts of the last successful build and use sbts IntegrationTest scope.

This is IMHO out of scope for native packager. I would definitely merge an example in the recipes section of the docs. 😀

[mdedetrich]

So this is a related issue, but I am not sure if he managed to figure out how to do it with sub-projects (i.e. dependsOn), #1157.

If you could provide a working example in recipes that would be fantastic!

[muuki88]

I forgot about the sub project part 😅 . This is tricky. Native packager doesn't really aggregate sub modules. You enable packaging for module and the classpath dependencies will be packaged as jars, but that's it.

Replicating sbt inside a package that you need to package with sbt. I would consider checking out the repository and run sbt test on it. If not possible, I would zip up the repo, e.g. sbt clean && zip . and ship that. You could include a runner like https://github.com/paulp/sbt-extras , so only a JRE needs to be installed.

SBT is a neat tool, but somethings like "replicate everything like task X" are as complex as sbt itself 😬

[mdedetrich]

Replicating sbt inside a package that you need to package with sbt. I would consider checking out the repository and run sbt test

Yeah this is the issue, for the way that CDP is set up at our work it greatly complicates things. It will substantially increase build times and will also cause us to build things twice. Trust me, if I could do it this way I would

Native packager doesn't really aggregate sub modules.

I wonder how difficult this would be? I might try doing some hacking on sbt-native-packager myself to see how hard this would be, I already asked a question on stack overflow which sbt's maintainer replied.

Would you be open to adding the ability to automatically aggregate sub-modules or is that still out of scope for you?

[muuki88]

Trust me, if I could do it this way I would

I do 😂 We had performance issues as well, but got to an acceptable level by running the regression tests in parallel on jenkins.

I wonder how difficult this would be? I might try doing some hacking on sbt-native-packager myself to see how hard this would be, I already asked a question on stack overflow which sbt's maintainer replied.

I'm not sure what the overall feature looks like. The issue you are having is two fold. One to create a test package. This is doable for a single module by using compile dependencies. Aggregating over sub modules in another scope is a different thing.

Maybe I phrased "native package doesn't really aggregate sub modules" wrong. Native packager aggregates classpath dependencies defined via dependsOn(...). The resulting distribution does have all in compile scope. So the requirement would be to

• have a "regression test" module that depends on the Compile and Test scope, or any other arbitrary scope. This should add all libraries required to run tests in the final distribution
• set the Compile / mainClass to the testframework runner

A scratch of a build.sbt may look like

lazy val regressionTestBundle = project.in(file("regression-test-bundle"))
   .enablePlugins(JavaAppPackaging)
   .settings(
      Compile / mainClass := Some("org.scalatest.tools.Runner")
    )
   .dependsOn(
     service1 % "compile->compile,compile->test",
     service2 % "compile->compile,compile->test"
   )

resources

• http://www.scalatest.org/user_guide/using_the_runner
• https://www.scala-sbt.org/1.x/docs/Multi-Project.html
• https://stackoverflow.com/questions/8193904/sbt-test-dependencies-in-multiprojects-make-the-test-code-available-to-dependen

[mdedetrich]

Perfect, I am going to try this out and see if it works.

[namutaka]

Thank you, I managed to do with bellow settings.

// Add bellow 2 lines
service1 / Test / packageBin / publishArtifact := true
service2 / Test / packageBin / publishArtifact := true

lazy val regressionTestBundle = project.in(file("regression-test-bundle"))
   .enablePlugins(JavaAppPackaging)
   .settings(
      Compile / mainClass := Some("org.scalatest.tools.Runner"),

      // (Optional) Add dependencyOverrides from service1 and service2 
      dependencyOverrides ++= (service1 / dependencyOverrides).value,
      dependencyOverrides ++= (service2 / dependencyOverrides).value
    )
   .dependsOn(
     service1 % "compile->compile,compile->test",
     service2 % "compile->compile,compile->test"
   )

[hikouki-gumo]

@mdedetrich Could you share how did you handle this problem?

Group all unit-tests to a module, and group all inter-tests to another module as muuki88 suggestion? Or did you manage to find a better way?

[mdedetrich]

@mdedetrich Could you share how did you handle this problem?

Group all unit-tests to a module, and group all inter-tests to another module as muuki88 suggestion? Or did you manage to find a better way?

I didn't end up implementing this since it was a technical problem in the previous company I worked at and I have since left.