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

wip: fix scripted tests #1

Merged
merged 24 commits into from
Dec 26, 2024

Conversation

jtjeferreira
Copy link

@jtjeferreira jtjeferreira commented Dec 4, 2024

Work in progress to fix scripted tests. Do you prefer to discuss here or in sbt#1647?

The biggest decision to make is what should target be? Keep backwards compatibility with ./target/universal? Use the new default target ( ./target/out/jvm/scala-3.3.3/universal )? Or something else like ./target/out/universal?

…sbt 2.x and project matrix target is target/out/jvm/scala-3.3.3/

alternatively we could change the Universal plugin so that config / target := baseDirectory.value / "target" / config.name
@eed3si9n
Copy link
Owner

eed3si9n commented Dec 5, 2024

Work in progress to fix scripted tests. Do you prefer to discuss here or in sbt#1647?

Either is fine. Thanks for this! I haven't done it yet, but I was thinking sbt should add some special scripted test command in the next 2.x version like exists-in-target or something, but hardcoding the target works for me too.

@jtjeferreira
Copy link
Author

jtjeferreira commented Dec 8, 2024

windows tests are faling with the error below because of sbt/sbt@d0003bb

Error:  java.nio.file.InvalidPathException: Illegal char <:> at index 90: C:\Users\runneradmin\AppData\Local\Temp\sbt_540f99c3\project\project\target\config-classes:C:\Users\RUNNER~1\AppData\Local\Temp\sbt_540f99c3\global\boot\scala-3.3.3\org.scala-sbt\sbt\2.0.0-M2\actions_3-2.0.0-M2.jar: ....
Error:  	at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
Error:  	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
Error:  	at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
Error:  	at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
Error:  	at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
Error:  	at java.nio.file.Paths.get(Paths.java:84)
Error:  	at dotty.tools.dotc.core.MacroClassLoader$.$anonfun$1(MacroClassLoader.scala:25)
Error:  	at scala.collection.immutable.List.map(List.scala:246)
Error:  	at dotty.tools.dotc.core.MacroClassLoader$.makeMacroClassLoader(MacroClassLoader.scala:25)
Error:  	at dotty.tools.dotc.core.MacroClassLoader$.init(MacroClassLoader.scala:19)
Error:  	at dotty.tools.dotc.Driver.setup(Driver.scala:79)
Error:  	at sbt.internal.Eval$EvalDriver.<init>(Eval.scala:55)
Error:  	at sbt.internal.Eval.driver$lzyINIT1(Eval.scala:47)
Error:  	at sbt.internal.Eval.driver(Eval.scala:47)
Error:  	at sbt.internal.Eval.compileAndLoad(Eval.scala:233)
Error:  	at sbt.internal.Eval.evalCommon(Eval.scala:214)
Error:  	at sbt.internal.Eval.eval(Eval.scala:121)

@jtjeferreira
Copy link
Author

the commits setting scalaVersion can be revert when sbt/sbt#7725 is fixed

@jtjeferreira
Copy link
Author

The biggest decision to make is what should target be? Keep backwards compatibility with ./target/universal? Use the new default target ( ./target/out/jvm/scala-3.3.3/universal )? Or something else like ./target/out/universal?

After thinking for this a while, I think we should use the new default target ( ./target/out/jvm/scala-3.3.3/universal ). It makes sense that sbt native packager plugin uses whatever the target key is defined to. It also makes sense that if one runs +stage, the results are in different directories (./target/out/jvm/scala-3.3.3/universal , ./target/out/jvm/scala-2.13/universal, ./target/out/js/scala-3.3.3/universal, etc). The only downside is that existing scripts that might depend on ./target/universal might have to be rewritten (like what happened in the scripted tests)

I haven't done it yet, but I was thinking sbt should add some special scripted test command in the next 2.x version like exists-in-target or something, but hardcoding the target works for me too.

I think that is a good idea

Comment on lines -7 to -8
import NativePackagerHelper._
Docker / mappings ++= directory("src/main/resources/docker-test")
Copy link
Author

Choose a reason for hiding this comment

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

@eed3si9n should sbt.io.Mapper#directory and other methods in sbt.io.Mapper that return mappings (i.e (File, String)) be changed to return ( (HashedVirtualFileRef, String) ) so it aligns with the changes to sbt.Keys#mappings which changed from using File to HashedVirtualFileRef?

Copy link
Owner

Choose a reason for hiding this comment

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

That makes sense.

Copy link
Author

Choose a reason for hiding this comment

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

unfortunately sbt.io.Mapper is in sbt/io which does not have access to HashedVirtualFileRef...

Copy link
Author

Choose a reason for hiding this comment

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

WDYT about reverting mappings to (File, String)? I gave it a try here

Copy link
Owner

Choose a reason for hiding this comment

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

File simultaneously is specific to user's environment, and not specific enough about the content, so it's inappropriate to participate in remote cache. For anything useful, mappings is going to be a critical input, so we have to make this change if we want remote caching to be a major feature of sbt 2.x. more details here
https://eed3si9n.com/sbt-remote-cache-with-bazel-compat/

Copy link
Owner

Choose a reason for hiding this comment

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

sbt/sbt for now?

Copy link
Author

Choose a reason for hiding this comment

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

sbt/sbt for now?

yes, but which package/class, so that is available in build.sbt files without import?

Copy link
Owner

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

Thanks. I will give it a try later today

Copy link
Author

Choose a reason for hiding this comment

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

@eed3si9n I tried this in sbt/sbt#7939 but I don't think this is enough.

File simultaneously is specific to user's environment, and not specific enough about the content, so it's inappropriate to participate in remote cache. For anything useful, mappings is going to be a critical input, so we have to make this change if we want remote caching to be a major feature of sbt 2.x. more details here
eed3si9n.com/sbt-remote-cache-with-bazel-compat

I understand these concerns, but making user code so verbose will make adoption of sbt 2.x a pain as it is a downgrade in quality from sbt 1.x

WDYT about reverting mappings to (File, String)?

cant we keep mappings key as (File, String), but move the cache implementation details to the task implementation? Even if it make task implementation more verbose?

@jtjeferreira
Copy link
Author

@eed3si9n as you can see here, the only failing test is related to this issue. The ConcurrentModificationException
issue
is still a problem, but it usually goes away after a retry of the job...

@eed3si9n
Copy link
Owner

Yea. It turns out Retry(...) only does IOExceptions, and what's failing is concurrent something.

@eed3si9n
Copy link
Owner

I'm going to merge this as-is.

@eed3si9n eed3si9n marked this pull request as ready for review December 26, 2024 23:29
@eed3si9n eed3si9n merged commit d6d2702 into eed3si9n:wip/cross Dec 26, 2024
11 of 14 checks passed
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.

2 participants