[2.x] Enable scripted test in CI

[Friendseeker]

Issue

When running scripted in sbt shell, the following error shows up

[error] stack trace is suppressed; run last zincScripted3 / update for the full output
[error] (zincScripted3 / update) sbt.librarymanagement.ResolveException: Error downloading org.scala-sbt:compiler-bridge_3:2.0.0-M2-SNAPSHOT
[error]   Not found
[error]   Not found
[error]   not found: /Users/jiahuitan/.ivy2/local/org.scala-sbt/compiler-bridge_3/2.0.0-M2-SNAPSHOT/ivys/ivy.xml
[error]   not found: https://repo1.maven.org/maven2/org/scala-sbt/compiler-bridge_3/2.0.0-M2-SNAPSHOT/compiler-bridge_3-2.0.0-M2-SNAPSHOT.pom

Fix

By removing

.configure(
    _.dependsOn(compilerBridge210, compilerBridge211, compilerBridge212, compilerBridge213)
 )

sbt would no longer fetch nonexistent org.scala-sbt/compiler-bridge_3.

Then by letting scripted task depends on publishBridges, ConstantBridgeProvider.fetchCompiledBridge can then access target directory of compilerBridge210, compilerBridge211, compilerBridge212, compilerBridge213, which then pick the right directory by calling ConstantBridgeProvider.bridgeOrBoom and package the directory with the matching scala version as a jar with naming starting withscriptedCompilerBridge-bin, which then gets renamed to target-bridge-$scalaVersion.jar in AbstractBridgeProviderTestkit.getCompilerBridge and be loaded via AnalyzingCompiler.getDualLoader.

Comment

I actually don't know if this an actual fix or just a workaround as I still don't know why exactly sbt is fetching nonexistent org.scala-sbt/compiler-bridge_3. But nonetheless I feel scripted test is very important and even if this is just a workaround, we should merge it to unblock CI.

[Friendseeker]

Ah CI is taking forever again...

Actually a good news as CI is catching the GZIP concurrency issue.

[adpi2]

I actually don't know if this an actual fix or just a workaround as I still don't know why exactly sbt is fetching nonexistent org.scala-sbt/compiler-bridge_3.

sbt always tries to resolve internal dependencies with Scala binary version. See for instance this:

ThisBuild / organization := "org.example"
ThisBuild / version := "1.0.0-SNAPSHOT"

lazy val a = project.settings(scalaVersion := "2.13.15")
lazy val b = project.settings(scalaVersion := "3.3.4").dependsOn(a)

b / update fails with "Error downloading org.example:a_3:1.0.0-SNAPSHOT"

In short, the settings of zincScripted looked incorrect and your fix looks good.

[adpi2]

@Friendseeker should we merge now or fixing the GZIP concurrency issue first?

[Friendseeker]

@Friendseeker should we merge now or fixing the GZIP concurrency issue first?

I am leaning towards merging the PR now, so the CI scripted test can reject improper fix of GZIP concurrency issue.

@eed3si9n What do you think?

[adpi2]

I am leaning towards merging the PR now, so the CI scripted test can reject improper fix of GZIP concurrency issue.

I agree, but it's probably not a good idea to freeze a runner for 5 hours.

[mzuehlke]

Maybe adding a timeout would help here: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes (default is 360 minutes)

[Friendseeker]

I agree, but it's probably not a good idea to freeze a runner for 5 hours.

Maybe adding a timeout would help here: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes (default is 360 minutes)

Thanks to both for the feedbacks. Just added a timeout.

[adpi2]

Thanks!