A plugin for assisting in building sbt projects using GitHub Actions, in the style of sbt-travisci. Unlike sbt-travisci, though, this plugin also provides a mechanism for generating GitHub Actions workflows from the sbt build definition. Conceptually, sbt-travisci allows Travis and sbt to jointly represent the "source of truth", while sbt-github-actions idiomatically vests that power solely in sbt.
Note that the generative functionality is optional and doesn't need to be used if undesired.
An example of how this "source of truth" pattern differs between the two plugins can be seen with crossScalaVersions
. With sbt-travisci, the crossScalaVersions
and scalaVersion
settings are populated from the scala:
key in .travis.yml. However, with sbt-github-actions, the scala:
entry in the job matrix:
is populated from the ThisBuild / crossScalaVersions
key in your build.sbt.
Add the following to your plugins.sbt
:
addSbtPlugin("com.codecommit" % "sbt-github-actions" % <latest>)
To use the generative functionality, run sbt githubWorkflowGenerate
and commit the results. If your sbt build is ever changed such that the generated workflow is no longer in sync, the workflow run in GitHub Actions will begin failing and you will need to re-run this task (and commit the results).
The GitHubActionsPlugin
provides general functionality, giving builds the ability to introspect on their host workflow and whether or not they are running in GitHub Actions. This latter functionality, exposed by the githubIsWorkflowBuild
global setting, is the most commonly used functionality of this plugin. If you need behavior within your build which is conditional on whether or not the build is running in CI, this is the setting you should branch on.
githubWorkflowName
and githubWorkflowDefinition
are designed to allow introspection on the exact definition of the workflow which is running the current build, if any. This kind of introspection is not common, but seems like it could be useful.
As mentioned above, the GenerativePlugin
is designed to make it easier to maintain GitHub Actions builds for sbt projects by generating ci.yml and clean.yml workflow definition files, and then forcibly failing the build if these files ever fall out of step with the build itself. The ci.yml workflow, by default, contains both build
and publish
jobs, though you will likely need to add extra steps to the githubWorkflowPublishPreamble
and/or githubWorkflowEnv
(e.g. decrypting and importing a GPG signing key) in order for publication to actually work.
If a publish
job is not desired, simply set githubWorkflowPublishTargetBranches
to Seq()
. By default, publish
is restricted to run on main
, and additional restrictions may be configured within the build.
Ivy, sbt, and Coursier caching are all handled by the generated ci.yml by default, as well as standard things like Git checkout, Scala setup (using Olafur's excellent setup-scala
action), and more. The matrix for the build
job will be generated from crossScalaVersions
and has additional support for multiple JVMs and OSes. Additionally, compiled artifacts are properly uploaded so that jobs which are dependent on build
can avoid redundant work (most notably, publish
). Thus, publication is guaranteed to be based on binary files that were generated and tested by the build
job, rather than re-generated by publish
. (NB: due to what appear to be issues in Zinc, this isn't quite working yet; expect it to be fixed in a coming release of sbt-github-actions)
clean.yml is generated based on a static description because it should just be the default in all GitHub Actions projects. This is basically a hack to work around the fact that artifacts produced by GitHub Actions workflows count against personal and organization storage limits, but those artifacts also are retained indefinitely up until 2 GB. This is entirely unnecessary and egregious, since artifacts are transient and only useful for passing state between jobs within the same workflow. To make matters more complicated, artifacts from a given workflow are invisible to the GitHub API until that workflow is finished, which is why clean.yml has to be a separate workflow rather than part of ci.yml. It runs on every push to the repository.
This plugin is quite prescriptive in that it forcibly manages the contents of the ci.yml and clean.yml files. By default, ci.yml will contain a step which verifies that its contents (and the contents of clean.yml) correspond precisely to the most up-to-date generated version of themselves. If this is not the case, then the build is failed. However, there is no restriction in adding other workflows not named ci.yml or clean.yml. These will be ignored entirely by the plugin.
Integrating with sbt-ci-release is a relatively straightforward process, and the plugins are quite complementary. First, follow all of the setup instructions in sbt-ci-release's readme. Once this is complete, add the following to your build.sbt:
ThisBuild / githubWorkflowTargetTags ++= Seq("v*")
ThisBuild / githubWorkflowPublishTargetBranches :=
Seq(RefPredicate.StartsWith(Ref.Tag("v")))
ThisBuild / githubWorkflowPublish := Seq(WorkflowStep.Sbt(List("ci-release")))
This is assuming that you only wish to publish tags. If you also wish to publish snapshots upon successful main builds, use the following githubWorkflowPublishTargetBranches
declaration:
ThisBuild / githubWorkflowPublishTargetBranches +=
RefPredicate.StartsWith(Ref.Tag("v"))
Note the use of +=
rather than :=
.
ThisBuild / githubWorkflowPublish := Seq(
WorkflowStep.Sbt(
List("ci-release"),
env = Map(
"PGP_PASSPHRASE" -> "${{ secrets.PGP_PASSPHRASE }}",
"PGP_SECRET" -> "${{ secrets.PGP_SECRET }}",
"SONATYPE_PASSWORD" -> "${{ secrets.SONATYPE_PASSWORD }}",
"SONATYPE_USERNAME" -> "${{ secrets.SONATYPE_USERNAME }}"
)
)
)
githubWorkflowGenerate
– Generates (and overwrites if extant) ci.yml and clean.yml workflows according to configuration within sbt. The clean.yml workflow is something that GitHub Actions should just do by default: it removes old build artifacts to prevent them from running up your storage usage (it has no effect on currently running builds). This workflow is unconfigurable and is simply drawn from the static contents of the clean.yml resource file within this repository.githubWorkflowCheck
– Checks to see if the ci.yml and clean.yml files are equivalent to what would be generated and errors if otherwise. This task is run from within the generated ci.yml to ensure that the build and the workflow are kept in sync. As a general rule, any time you change the workflow configuration within sbt, you should regenerate the ci.yml and commit the results, but inevitably people forget. This check fails the build if that happens. Note that if you need to manually fiddle with the ci.yml contents, for whatever reason, you will need to remove the call to this check from within the workflow, otherwise your build will simply fail.
githubIsWorkflowBuild
:Boolean
– Indicates whether or not the build is currently running within a GitHub Actions WorkflowgithubWorkflowName
:String
– The name of the currently-running workflow. Will be undefined if not running in GitHub Actions.githubWorkflowDefinition
:Map[String, Any]
– The raw (parsed) contents of the workflow YAML definition. Will be undefined if not running in GitHub Actions, or if (for some reason) the workflow could not be identified. Workflows are located by taking thegithubWorkflowName
and finding the YAML definition which has the correspondingname:
key/value pair.
Any and all settings which affect the behavior of the generative plugin should be set in the ThisBuild
scope (for example, ThisBuild / crossScalaVersions :=
rather than just crossScalaVersions :=
). This is important because GitHub Actions workflows are global across the entire build, regardless of how individual projects are configured. A corollary of this is that it is not possible (yet) to have specific subprojects which build with different Scala versions, Java versions, or OSes. This is theoretically possible but it's very complicated. For now, I'm going to be lazy and wait for someone to say "pretty please" before implementing it.
githubWorkflowGeneratedCI
:Seq[WorkflowJob]
— Contains a description of the ci.yml jobs that will drive the generation if used. This setting can be overridden to customize the jobs (e.g. by adding additional jobs to the workflow).githubWorkflowGeneratedUploadSteps
:Seq[WorkflowStep]
– Contains a list of steps which are used to upload generated intermediate artifacts from thebuild
job. This is mostly for reference and introspection purposes; one would not be expected to change this setting.githubWorkflowGeneratedDownloadSteps
:Seq[WorkflowStep]
– Contains a list of steps which are used to download generated intermediate artifacts from thebuild
job. This is mostly for reference and introspection purposes; one would not be expected to change this setting. This setting is particularly useful in conjunction withgithubWorkflowAddedJobs
: if you're adding a job which needs access to intermediate artifacts, you should make sure these steps are part of the process.githubWorkflowGeneratedCacheSteps
:Seq[WorkflowStep]
– Contains a list of steps which are used to set up caching for ivy, sbt, and coursier artifacts (respecting changes to files which contain versioning information). This is mostly for reference and introspection purposes; one would not be expected to change this setting. This setting is particularly useful in conjunction withgithubWorkflowAddedJobs
: if you're adding a job which needs to use sbt, you should probably ensure that these steps are part of the job.githubWorkflowSbtCommand
:String
– Any use of sbt within the generated workflow will compile to an invocation of this bash command. This defaults to"sbt"
, but can be overridden to anything that is valid in bash syntax (e.g."csbt"
, or"$SBT"
).githubWorkflowUseSbtThinClient
:Boolean
– Controls whether or not the--client
option will be added tosbt
command invocations, accelerating build times (default:true
for sbt ≥ 1.4,false
otherwise)githubWorkflowDependencyPatterns
:Seq[String]
– A list of file globs which dictate where dependency information is stored. This is conventionally just**/*.sbt
andproject/build.properties
. If you store dependency information in some other file (for example,project/Versions.scala
), then you should add a glob which matches that file in this setting. This is used for determining the appropriate cache keys for the Ivy and Coursier caches.githubWorkflowTargetBranches
:Seq[String]
– A list of globs which will match branches and tags forpush
andpull-request
event types to trigger the ci.yml workflow. Defaults to[*]
.githubWorkflowTargetTags
:Seq[String]
– A list of globs which will match tags and tags forpush
event types to trigger the ci.yml workflow. Defaults to[]
.githubWorkflowPREventTypes
:Seq[PREventType]
– A list of event types which will be used to determine which Pull Request events trigger the ci.yml workflow. This follows GitHub's defaults:[opened, synchronize, reopened]
.githubWorkflowArtifactUpload
:Boolean
– Controls whether or not to upload target directories in the event that multiple jobs are running sequentially. Can be set on a per-project basis. Defaults totrue
.githubWorkflowJobSetup
:Seq[WorkflowStep]
– The automatically-generated checkout, setup, and cache steps which are common to all jobs which touch the build (default: autogenerated)githubWorkflowEnv
:Map[String, String]
– An environment which is global to the entire ci.yml workflow. Defaults toMap("GITHUB_TOKEN" -> "${{ secrets.GITHUB_TOKEN }}")
since it's so commonly needed.githubWorkflowAddedJobs
:Seq[WorkflowJob]
– A convenience mechanism for adding extra custom jobs to the ci.yml workflow (though you can also do this by modifyinggithubWorkflowGeneratedCI
). Defaults to empty.
githubWorkflowBuildMatrixFailFast
:Option[Boolean]
– Whether or not to enable thefail-fast
strategy for thebuild
job. By default, no strategy option is written to the build configuration (None
), which means that thefail-fast
strategy is used.githubWorkflowBuildMatrixAdditions
:Map[String, List[String]]
– Contains a map of additionalmatrix:
dimensions which will be added to thebuild
job (on top of the auto-generated ones for Scala/Java/JVM version). As an example, this can be used to manually achieve additional matrix expansion for ScalaJS compilation. Matrix variables can be referenced in the conventional way within steps by using the${{ matrix.keynamehere }}
syntax. Defaults to empty.githubWorkflowBuildMatrixInclusions
:Seq[MatrixInclude]
– A list of matrix inclusions. This is useful for when you have a specific matrix job which needs to do extra work, or wish to add an individual matrix job to the configuration set. The matching keys and values are verified against the known matrix configuration. Defaults to empty.githubWorkflowBuildMatrixExclusions
:Seq[MatrixExclude]
– A list of matrix exclusions. This is useful for when there is a matrix expansion (or set of expansions) which you wish to filter out of the set. Note that exclusions are applied before inclusions, allowing you to subtract jobs before re-adding them. Also – and the documentation isn't clear on this point – it is possible that the matching must cover the full set of matrix keys and cannot contain partial values. Defaults to empty.githubWorkflowBuildPreamble
:Seq[WorkflowStep]
– Contains a list of steps which will be inserted into thebuild
job in the ci.yml workflow after setup but before thesbt test
invocation. Defaults to empty.githubWorkflowBuildPostamble
:Seq[WorkflowStep]
– Similar to thePreamble
variant, this contains a list of steps which will be added to thebuild
job after thesbt test
invocation but before cleanup. Defaults to empty.githubWorkflowBuild
:Seq[WorkflowStep]
– The steps which invoke sbt (or whatever else you want) to build and test your project. This defaults to just[sbt test]
, but can be overridden to anything. For example, sbt plugin projects probably want to redefine this to beSeq(WorkflowStep.Sbt(List("test", "scripted")))
, which would run thetest
andscripted
sbt tasks, in order. Note that all uses ofWorkflowStep.Sbt
are compiled using the configuredgithubWorkflowSbtCommand
invocation, and properly configured with respect to the build matrix-selected Scala version.githubWorkflowJavaVersions
:Seq[String]
– A list of Java versions, using Jabba syntax, which will be used tobuild
your project. Note that thepublish
job will always run under the very first of these versions. Defaults to[[email protected]]
.githubWorkflowScalaVersions
:Seq[String]
– A list of Scala versions which will be used tobuild
your project. Defaults tocrossScalaVersions
inbuild
, and simplyscalaVersion
inpublish
.githubWorkflowOSes
:Seq[String]
– A list of operating systems, which will be ultimately passed to theruns-on:
directive, on which tobuild
your project. Defaults toubuntu-latest
. Note that, regardless of the value of this setting, onlyubuntu-latest
will be used for thepublish
job. This setting only affectsbuild
.githubWorkflowBuildRunsOnExtraLabels
:Seq[String]
- A list of additional runs-on labels, which will be combined with the matrix.os fromgithubWorkflowOSes
above allowing for singling out more specific runners.
githubWorkflowPublishPreamble
:Seq[WorkflowStep]
– Similar togithubWorkflowBuildPreamble
, this contains a series of steps which will be inserted into thepublish
job after setup but before the publication step. Defaults to empty.githubWorkflowPublishPostamble
:Seq[WorkflowStep]
– Similar to thePreamble
variant, this contains a series of steps which will be inserted into thepublish
job after publication has completed, but before cleanup. Defaults to empty.githubWorkflowPublish
:Seq[WorkflowStep]
– The steps which will be invoked to publish your project. This defaults to[sbt +publish]
.githubWorkflowPublishTargetBranches
:Seq[RefPredicate]
– A list of branch predicates which will be applied to determine whether thepublish
job will run. Defaults to just== main
. The supports all of the predicate types currently allowed by GitHub Actions. This exists because, while you usually want to run thebuild
job on every branch,publish
is obviously much more limited in applicability. If this list is empty, then thepublish
job will be omitted entirely from the workflow.githubWorkflowPublishCond
:Option[String]
– This is an optional added conditional check on the publish branch, which must be defined using GitHub Actions expression syntax, which will be conjoined to determine theif:
predicate on thepublish
job. Defaults toNone
.