Install SBT on self-hosted gha runners V2 #11
Conversation
- Downloads the sbt tar file to `$RUNNER_TEMP/_sbt` - Extracts the sbt files to `$RUNNER_TOOL_CACHE/sbt/version` - Check the tool cache for sbt before bothering to pull it from the cache or download it. - Check the actions/cache if its not in the tool cache.
|
As the logic here gets more complex, it may be less error prone to write an action Javascript and use (and not reimplement) the tool-cache library: https://docs.github.com/en/actions/sharing-automations/creating-actions/developing-a-third-party-cli-action |
|
I would like to hold off on using JavaScript as much as possible because I don't understand it. |
Instead of caching the download path, we cache directly the toolpath. We continue first checking that the sbt installation is not already on the toolpath where we would expect it to be. Additionally, this combines the install and download phases since we don't cache the download sbt dir, but the tooldir anymore anyways.
| uses: actions/cache@v4 | ||
| with: | ||
| path: ${{ steps.cache-paths.outputs.setupsbt_path }} | ||
| key: ${{ runner.os }}-sbt-${{ inputs.sbt-runner-version }}-1.1.1 | ||
| path: ${{ steps.cache-paths.outputs.sbt_toolpath }} |
There was a problem hiding this comment.
Note: because the $RUNNER_TOOL_CACHE path can be different between self-hosted and hosted runners, they may not be able to share this cache (actions/cache uses the paths in the cache key), but have separate caches. In practice I don't think this matters because of how fast the curl is, and how few different versions of sbt will need to be cached (its not like the cache between the build and test and publish on the typical sbt-typelevel project where its important to not rebuild the project).
|
Thank you! |
|
@zarthross I pushed https://github.com/sbt/setup-sbt/releases/tag/v1.1.2. Let us know if it worked in your environment. |
|
Worked perfectly, thanks for your help and feedback! |
$RUNNER_TEMP/_sbt$RUNNER_TOOL_CACHE/sbt/version