Add setup-sbt to workflow #38
Conversation
| uses: actions/setup-java@v4 | ||
| with: | ||
| distribution: corretto | ||
| java-version: 11 |
There was a problem hiding this comment.
Since .tool-versions specifies Java 21, this is a change in the Java version used for compilation from 11 to 21, which I reckon requires a bit more testing. I think we should keep the version at 11 in this PR by leaving setup-java as-is and adding setup-sbt, instead of using setup-scala. (Once we've updated this to Java 21 we can then move to setup-scala.)
There was a problem hiding this comment.
As @kelvin-chappell pointed out on another PR, the fact that this repo is using the gha-scala-release-workflow means that the java version in .tool-versions is already being used to build the library!
So this only changes what's used for tests in CI: since those have passed, we’re fine to merge this PR as-is.
(We should look into whether we need to add a --release flag or similar to support older java versions among our consumers.)
|
I forgot to explicitly approve this PR, but I have unofficially approved it |
What does this change?
As we're so dependent on sbt and the sbt launcher hence we should provide this in our workflow so that external dependency wouldn't matter such as we had failed workflows on upgraded version of ubuntu recently because it has no sbt information in it.
So, to save us from these kind of issues we will provide our own setup-sbt as an action to resolve sbt easily.
How to test
Raise this PR and observe running CI.
How can we measure success?
Build should run as normal and no failing CI should be observed.