I found this setting under Actions:

Working on adding this plugin in cb372/scalacache#470 and I had to actually add an extra workflow step:

WorkflowStep.Sbt(List("benchmarks/compile"), name = Some("Compile Benchmarks"))

because the benchmarks were not being compiled at all or run in the CI pipeline. This means that no target/ directory was created for benchmarks and so the tar in the Compression step of the pipeline was failing out.

Not sure if it is really feasible to fix this situation or not. But I thought I would at least post an issue here for there to be a record of my workaround when encountering this.

I'll close this, I just wanted to say thanks for doing this. I followed the instructions and it worked just as expected the first time! Kudos!

This plugin has three functions:

1. Make SBT the source of truth for the Github Actions matrix of Scala versions, etc.
2. A DSL for defining your entire workflow from within your SBT build
3. A standard set of workflows that works well for most projects, using sbt-ci-release.

If one only needed (3), an SBT plugin would be unnecessary. (2) is very nice for those that are more comfortable doing things that way. And once you're doing things that way, the whole sbt githubWorkflowGenerate / sbt githubWorkflowCheck becomes necessary.

And it is a pain point, because it's too easy to forget to run sbt githubWorkflowGenerate. Fortunately Scala Steward knows to run it.

But the reality is that the value for most people is probably (1). And I think it may be possible to support without the whole sbt githubWorkflowGenerate / sbt githubWorkflowCheck dance.

I found a few articles about how to define a dynamic matrix. Here is one of them: https://brunoscheufler.com/blog/2021-10-09-generating-dynamic-github-actions-workflows-with-the-job-matrix-strategy

The basic idea is that an earlier step can generate output that the next step can parse as its matrix.

So there could be an SBT task to print out the matrix data, and the workflow could be written to use it to define the matrix. Then every time the Scala versions change or you add a subproject, ci.yml doesn't have to change.

My use case for needing sub-projects with different Scala versions is when there are 2 sub-projects, one that is a Scala library that is cross built for Scala 2.12 and 2.13 and another sub-project which is an sbt plugin that can only be built with Scala 2.12.

Noticed this in ip4s. The js/target directory had 7302 files, resulting in an upload of over 4 minutes: https://github.com/Comcast/ip4s/runs/1003331942?check_suite_focus=true#step:14:12

Hi!

Sometimes you want to drop the cache without necessarily changing the paths it depends on, so just a "drop cache" button would be nice to have. Sadly, actions/cache doesn't have that ability (actions/cache#2), so we need a workaround.

I used this to work around, but maybe it's something that could be a key? (e.g. the cacheOffset value):

//Increment this every time you want to drop the caches
val cacheOffset = 1

ThisBuild / githubWorkflowGeneratedCacheSteps ~= { steps =>
  steps.map {
    case u @ WorkflowStep.Use("actions", "cache", _, params, _, _, _, _) =>
      u.copy(params = params.map {
        case (k @ "key", cacheKey) => (k, s"$cacheKey-v$cacheOffset")
        case (k, v)                => (k, v)
      })
    case x                                                               => x
  }
}

For instance, I think I would need something like this: https://docs.github.com/en/actions/guides/creating-postgresql-service-containers

Any files that are generated by the githubWorkflowGenerate don't have a newline at the end of the file. Its recommended to have newlines at the end of any source files to help with compatibility issues between *nix and Windows.

I noticed this when creating a PR that github complains about missing newlines at the end of the file.

Right now the plugin doesn't offer an option to rerun the workflow with a cron-job schedule. It would be a nice new feature, given that it happens that builds get stale with time.

• this would default to the value of githubWorkflowScalaVersions (which defaults to crossScalaVersions)
• it would control which versions of scala have jars published
• specifically, I would like to have crossScalaVersions contain 3.0.2 and 3.1.0 (so I can test with both versions) but only publish for scala 3.0.2. My understanding is that for maximum Scala 3 compatibility, it is best to publish Scala 3 artifacts that are built with scala 3.0.x. These will run ok on Scala 3.1.x. But artifacts built with Scala 3.1.x won't work on Scala 3.0.x. See https://twitter.com/SethTisue/status/1450260785762947076

This is more of a suggestion but it seems like a lot of people are having problems with sbt's thin client mode (see sbt/sbt#6468). An issue I just found is that currently when SBT runs with --client it ignores all environment variables which makes the env field for WorkflowStep.Sbt not even work (you can see the PR at iheartradio/ficus#155 where I had to set this to false because sbt-coveralls cannot even pick up the env vars)

My suggestion would be to set it completely to false until the problems with a new SBT release.

As a possible alternative to #39, would there be any interest in something like the following rough draft? Basically it keeps the jobs in .mergify.yml up to date when running githubWorkflowGenerate:

import java.io.{File, FileInputStream}
import java.{util => ju}

import scala.collection.JavaConverters._
import scala.util.matching.Regex

import org.yaml.snakeyaml.Yaml
import sbt.AutoPlugin
import sbt.io.IO
import sbtghactions.GenerativeKeys.{githubWorkflowGenerate, githubWorkflowGeneratedCI}
import sbtghactions.GenerativePlugin


object Mergify extends AutoPlugin {
  override def requires = GenerativePlugin
  override def trigger = allRequirements

  type Dict = ju.Map[String, AnyRef]

  override def projectSettings = Seq(
    githubWorkflowGenerate := {
      githubWorkflowGenerate.value
      githubWorkflowGeneratedCI.value
        .find(_.id == "build")
        .foreach { job =>
          val yaml = new Yaml
          val res = yaml.load[Dict](new FileInputStream(".mergify.yml"))
          val conditions =
            res
              .get("pull_request_rules").asInstanceOf[ju.List[Dict]].asScala.map(_.asScala)
              .find(_ ("name") == "Automatically merge successful scala-steward PRs").get
              .apply("conditions").asInstanceOf[ju.List[String]].asScala

          val existing = conditions.filter(_.matches(s"status-success=${Regex.quote(job.name)} \\(.*\\)"))
          conditions --= existing

          val concreteJobNames = for (o <- job.oses; s <- job.scalas; v <- job.javas) yield s"${job.name} ($o, $s, $v)"

          conditions ++= concreteJobNames.map(name => s"status-success=$name")

          IO.write(new File(".mergify.yml"), yaml.dumpAsMap(res))
        }
    }
  )
}

Tried to disable publish job by setting keys like this in my build.sbt to address #4 .

ThisBuild / githubWorkflowPublishTargetBranches := List()
ThisBuild / githubWorkflowJavaVersions := List("[email protected]")

And got this error in GitHub Actions:

[error] java.lang.RuntimeException: ci.yml does not contain contents that would have been generated by sbt-github-actions; try running githubWorkflowGenerate

Seems like unexpected behavior to me. Or maybe I've missed something again. :)

• change seems to be driven by actions/setup-java#290
• other actions like checkout and cache have similar v3 releases

GitHub workflows have now a feature in beta, concurrency. One can read more in here: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency

The feature enables to stop an already running workflow when a new one is enqueued. Enabling this would save lots of time on CI servers for jobs that are already obsolete.
To configure it, this should be added to the continuous integration yml file:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

@djspiewak Would you consider adding this feature even though is still in Beta on GitHub side? I would be willing to contribute it.

I would like to have a separate environment for each job.

The main reason for this is the lack of tag protection in GitHub (branch protection rules do not apply and so anyone who can push a tag can trigger a release).

There is a nice solution to this which is to have a release environment for the release job which can have its own approval.

The example from github blog is:

        # disable command workflow processing
        echo "::stop-commands::`echo -n ${{ github.token }} | sha256sum | head -c 64`"

        # log untrusted output
        echo "untrusted output"

        # enable workflow command processing
        echo "::`echo -n ${{ github.token }} | sha256sum | head -c 64`::"

The disable/enable is constant, so they could be provided as actions. Better yet, though, would be a withUntrusted or withCommandsDisabled workflow step that takes other workflow steps as input, and runs then with commands disabled as above.

In order to do generate a github-actions which do some operations other than read we get unauthorised error when PR is created from forks e.g Commenting on PR, Adding labels etc.
It is suggested to use pull_request_target in such use cases.

For example, I want to trigger workflow on pull_request to all branches but only on push to "main" branch. Otherwise, there will be two identical workflows if I push and open pull_requests to the same repo without fork.

How can I configure with option in sbt-github-action WorkflowStep.Use when github actions yaml like below is needed?

- name: Do Something
        uses: foo/bar@v1
        with:
          param1: ${{ secrets.param1}}
          param2: ${{secrets.param2}}

At present, artifact uploading is hard-coded to the default set of matrix keys (OS, Java, and Scala). Custom matrices are also possible and should be detected so as to avoid overwriting (and possibly corrupting!) artifacts from other jobs.

If sbt-crossproject is detected, we should generate a project matrix which corresponds to its usage. This is going to be… more than a little tricky. Probably possible though. The point being that people shouldn't have to manually fiddle with the generated build workflow in order to get parallel JavaScript builds.

For the record, these things all work now, it's just that you can get a prettier and more parallel workflow with better matrix support.

Currently the workflow jobs created by this plugin have some parts of the build environment appended to the name, e.g.

Build and Test (ubuntu-latest, 2.13.6, [email protected])

GitHub lets me specify that the jobs must succeed in order to merge a PR - by name:

However, if a PR changes the Scala or Java version it will be problematic to merge without disabling the rule.

In fact, I don't think I'm in control of the Java version or the "ubuntu-latest" part either.

I'd like to have an option to only have the critical pieces of environment (e.g. "Scala 2.13") in the job name, and omit everything else.

What

Could you/we add support for changing the runs-on setting for the publish job too?

Why

For self-hosted runners, you need to set a custom githubWorkflowOSes. It then gets set on the build job, but not on the publish job (as you've documented in the Readme).

However, since we have a private Maven repo (Nexus), we'd like to be able to publish into that using our self-hosted runners.

This error occurs:

Run tar cf targets.tar modules/user-service-api/target target target/lagom-dynamic-projects/lagom-internal-meta-project-kafka/target target/lagom-dynamic-projects/lagom-internal-meta-project-service-locator/target target/lagom-dynamic-projects/lagom-internal-meta-project-cassandra/target project/target
8
tar: target/lagom-dynamic-projects/lagom-internal-meta-project-kafka/target: Cannot stat: No such file or directory
9
tar: target/lagom-dynamic-projects/lagom-internal-meta-project-service-locator/target: Cannot stat: No such file or directory
10
tar: target/lagom-dynamic-projects/lagom-internal-meta-project-cassandra/target: Cannot stat: No such file or directory
11
tar: Exiting with failure status due to previous errors
12
Error: Process completed with exit code 2.

The problem is rooted in Lagom adding "dynamic" modules to the project which then get added (I think) to internalTargetAggregation. These targets wouldn't be useful for adjacent jobs. On a pristine project—even after test is run—those paths still won't be present. And, of course, they're already considered by virtue of the tar command including target.

My first thought is there's two ways to address this:

1. Whitelist which modules should be uploaded (given where I'm at on the learning curve with GitHub Actions and this project, not sure if that's sensible).
2. Make the tar command tolerant of missing directories.

https://repo1.maven.org/maven2/com/codecommit/sbt-github-actions_2.12_1.0/0.14.2/sbt-github-actions-0.14.2.pom contains this:

<scm>
<url>
https://github.com/djspiewak/sbt-github-actions.git
</url>
<connection>
scm:git:https://github.com/djspiewak/sbt-github-actions.git.git
</connection>
<developerConnection>
scm:git:[email protected]:djspiewak/sbt-github-actions.git.git
</developerConnection>
</scm>

Each URL/connection has an extra .git suffix which is the reason why Scala Steward couldn't link to the release notes of 0.14.2. I've no idea where this extra .git is coming from.

sbt 1.5.5
sbt github action 0.13.0

When i trying to run a built on github im getting this weird error , does anyone have any clue ?

stack trace

Run sbt ++2.13.6 githubWorkflowCheck
downloading sbt launcher 1.5.5
copying runtime jar...
[info] [launcher] getting org.scala-sbt sbt 1.5.5  (this may take some time)...
[info] [launcher] getting Scala 2.12.14 (for sbt)...
java.lang.ClassCastException: class java.io.IOException cannot be cast to class xsbti.FullReload (java.io.IOException is in module java.base of loader 'bootstrap'; xsbti.FullReload is in unnamed module of loader 'app')
	at sbt.internal.XMainConfiguration.run(XMainConfiguration.java:59)
	at sbt.xMain.run(Main.scala:46)
	at xsbt.boot.Launch$.$anonfun$run$1(Launch.scala:149)
	at xsbt.boot.Launch$.withContextLoader(Launch.scala:176)
	at xsbt.boot.Launch$.run(Launch.scala:149)
	at xsbt.boot.Launch$.$anonfun$apply$1(Launch.scala:44)
	at xsbt.boot.Launch$.launch(Launch.scala:159)
	at xsbt.boot.Launch$.apply(Launch.scala:44)
	at xsbt.boot.Launch$.apply(Launch.scala:21)
	at xsbt.boot.Boot$.runImpl(Boot.scala:78)
	at xsbt.boot.Boot$.run(Boot.scala:73)
	at xsbt.boot.Boot$.main(Boot.scala:21)
	at xsbt.boot.Boot.main(Boot.scala)
Error:  [launcher] error during sbt launcher: java.lang.ClassCastException: class java.io.IOException cannot be cast to class xsbti.FullReload (java.io.IOException is in module java.base of loader 'bootstrap'; xsbti.FullReload is in unnamed module of loader 'app')Run sbt ++2.13.6 githubWorkflowCheck
downloading sbt launcher 1.5.5
copying runtime jar...
[info] [launcher] getting org.scala-sbt sbt 1.5.5  (this may take some time)...
[info] [launcher] getting Scala 2.12.14 (for sbt)...
java.lang.ClassCastException: class java.io.IOException cannot be cast to class xsbti.FullReload (java.io.IOException is in module java.base of loader 'bootstrap'; xsbti.FullReload is in unnamed module of loader 'app')
	at sbt.internal.XMainConfiguration.run(XMainConfiguration.java:59)
	at sbt.xMain.run(Main.scala:46)
	at xsbt.boot.Launch$.$anonfun$run$1(Launch.scala:149)
	at xsbt.boot.Launch$.withContextLoader(Launch.scala:176)
	at xsbt.boot.Launch$.run(Launch.scala:149)
	at xsbt.boot.Launch$.$anonfun$apply$1(Launch.scala:44)
	at xsbt.boot.Launch$.launch(Launch.scala:159)
	at xsbt.boot.Launch$.apply(Launch.scala:44)
	at xsbt.boot.Launch$.apply(Launch.scala:21)
	at xsbt.boot.Boot$.runImpl(Boot.scala:78)
	at xsbt.boot.Boot$.run(Boot.scala:73)
	at xsbt.boot.Boot$.main(Boot.scala:21)
	at xsbt.boot.Boot.main(Boot.scala)
Error:  [launcher] error during sbt launcher: java.lang.ClassCastException: class java.io.IOException cannot be cast to class xsbti.FullReload (java.io.IOException is in module java.base of loader 'bootstrap'; xsbti.FullReload is in unnamed module of loader 'app')

plugins.sbt

addSbtPlugin("org.xerial.sbt" % "sbt-pack" % "0.14")
addSbtPlugin("com.github.regis-leray" % "sbt-docker-image" % "0.7.1")
addSbtPlugin("com.github.sbt" % "sbt-ci-release"     % "1.5.10")
addSbtPlugin("com.codecommit" % "sbt-github-actions" % "0.13.0")

build.sbt

val GraalVM11 = "[email protected]"

ThisBuild / scalaVersion := "2.13.6"
ThisBuild / organization := "com.regis"
ThisBuild / Test / fork := true
ThisBuild / Test / parallelExecution := false
ThisBuild / githubWorkflowJavaVersions := Seq(GraalVM11)
ThisBuild / versionScheme := Some("early-semver")

ThisBuild / githubWorkflowBuildPreamble ++= Seq(
  WorkflowStep.Run(
    List(
      "docker-compose -f \"docker-compose.yml\" up -d --build",
    ),
    name = Some("Start containers")
  )
)

ThisBuild / githubWorkflowBuild := Seq(
  WorkflowStep.Sbt(List("test"))
)

//sbt-ci-release settings
ThisBuild / githubWorkflowPublishPreamble := Seq(
  WorkflowStep.Use(UseRef.Public("olafurpg", "setup-gpg", "v3"))
)

ThisBuild / githubWorkflowTargetTags ++= Seq("v*")
ThisBuild / githubWorkflowPublishTargetBranches := Seq(
  RefPredicate.StartsWith(Ref.Branch("master")),
  RefPredicate.StartsWith(Ref.Tag("v"))
)

val doobieVersion = "0.12.1"
val http4sVersion = "0.21.20"
val circeVersion = "0.13.0"
val csvVersion = "0.6.2"

lazy val root = (project in file("."))
  .settings(
    name := "ambassadors-service",
    scalacOptions ++= Seq(
      "-encoding", "UTF-8",
      "-unchecked",
      "-deprecation",
      "-feature",
      //"-Xlint",
      "-Xlint:_,-byname-implicit",
      "-Xfatal-warnings",
    ),
    scalacOptions ++= Seq(
      "-language:higherKinds",
      "-language:postfixOps",
    ),
    libraryDependencies ++= Seq(
      "org.http4s" %% "http4s-blaze-server" % http4sVersion,
      "org.http4s" %% "http4s-blaze-client" % http4sVersion,
      "org.http4s" %% "http4s-dsl" % http4sVersion,
      "org.http4s" %% "http4s-circe" % http4sVersion,

      "io.circe" %% "circe-core" % circeVersion,
      "io.circe" %% "circe-generic" % circeVersion,
      "io.circe" %% "circe-parser" % circeVersion,

      "org.tpolecat" %% "doobie-core" % doobieVersion,
      "org.tpolecat" %% "doobie-postgres" % doobieVersion,
      "org.tpolecat" %% "doobie-hikari" % doobieVersion,
      "org.tpolecat" %% "doobie-scalatest" % doobieVersion % Test,

      "com.github.fs2-blobstore" %% "s3" % "0.7.3",

      "com.sun.mail" % "javax.mail" % "1.6.2",
      "com.icegreen" % "greenmail" % "1.3" % Test,

      "com.typesafe" % "config" % "1.4.1",
      "org.flywaydb" % "flyway-core" % "7.2.0",

      "org.slf4j" % "slf4j-api" % "1.7.32",
      "org.apache.logging.log4j" % "log4j-api" % "2.13.3",
      "org.apache.logging.log4j" % "log4j-core" % "2.13.3",
      "org.apache.logging.log4j" % "log4j-slf4j-impl" % "2.13.3",

      "com.nrinaudo" %% "kantan.csv" % csvVersion,
      "com.nrinaudo" %% "kantan.csv-generic" % csvVersion,
      "com.nrinaudo" %% "kantan.csv-java8" % csvVersion,

      "org.scalatest" %% "scalatest" % "3.2.10" % Test
    ),
    packMain := Map(
      "ambassadors" -> "com.trampoline.xx.Server"
    )
  )
  .enablePlugins(PackPlugin, DockerImagePlugin)

If it's supposed to delete artifacts from previous actions, why am I still able to download them or delete them?

From the Cats Effect 3 build:

This is how the build used to be (GraalVM was a String).

  // Nice-to-haves but unreliable in CI
  val flakyFilters = Seq(
    MatrixExclude(Map("os" -> Windows, "java" -> GraalVM))
  )

This now results in a compile error, which is fine, calling .render should fix it.

However, that results in the following error:

sbt:root> last githubWorkflowGenerate
[error] java.lang.RuntimeException: inclusion key `java` was present in matrix, but value `temurin@11` was not in List(JavaSpec(Temurin,8), JavaSpec(Temurin,11), JavaSpec(Temurin,17), JavaSpec(GraalVM(21.3),11))
[error]         at scala.sys.package$.error(package.scala:30)
[error]         at sbtghactions.GenerativePlugin$.$anonfun$compileJob$12(GenerativePlugin.scala:355)
[error]         at sbtghactions.GenerativePlugin$.$anonfun$compileJob$12$adapted(GenerativePlugin.scala:348)
[error]         at scala.collection.immutable.Map$Map2.foreach(Map.scala:273)
[error]         at sbtghactions.GenerativePlugin$.checkMatching$1(GenerativePlugin.scala:348)
[error]         at sbtghactions.GenerativePlugin$.$anonfun$compileJob$15(GenerativePlugin.scala:378)
[error]         at sbtghactions.GenerativePlugin$.$anonfun$compileJob$15$adapted(GenerativePlugin.scala:378)
[error]         at scala.collection.immutable.List.foreach(List.scala:431)
[error]         at sbtghactions.GenerativePlugin$.compileJob(GenerativePlugin.scala:378)
[error]         at sbtghactions.GenerativePlugin$.$anonfun$compileWorkflow$8(GenerativePlugin.scala:471)
[error]         at scala.collection.immutable.List.map(List.scala:293)
[error]         at sbtghactions.GenerativePlugin$.compileWorkflow(GenerativePlugin.scala:471)
[error]         at sbtghactions.GenerativePlugin$.$anonfun$generateCiContents$1(GenerativePlugin.scala:702)
[error]         at scala.Function1.$anonfun$compose$1(Function1.scala:49)
[error]         at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:62)
[error]         at sbt.std.Transform$$anon$4.work(Transform.scala:68)
[error]         at sbt.Execute.$anonfun$submit$2(Execute.scala:282)
[error]         at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:23)
[error]         at sbt.Execute.work(Execute.scala:291)
[error]         at sbt.Execute.$anonfun$submit$1(Execute.scala:282)
[error]         at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:265)
[error]         at sbt.CompletionService$$anon$2.call(CompletionService.scala:64)
[error]         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error]         at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
[error]         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error]         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
[error]         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
[error]         at java.base/java.lang.Thread.run(Thread.java:833)
[error] (githubWorkflowGenerate) inclusion key `java` was present in matrix, but value `temurin@11` was not in List(JavaSpec(Temurin,8), JavaSpec(Temurin,11), JavaSpec(Temurin,17), JavaSpec(GraalVM(21.3),11))

What's your thoughts on adding a githubWorkflowBuildPostamble?
(compared to existing githubWorkflowBuildPreamble)

I imagine it could be used for things like annotating from jUnit test reports:
https://github.com/marketplace/actions/junit-report-to-annotations

For example, in build.sbt:

ThisBuild / githubWorkflowBuildPostamble := Seq(
  WorkflowStep.Use(
    "ashley-taylor",
    "junit-report-annotations-action",
    "v1.0",
    name = Some(s"jUnit report"),
    cond = Some(s"always()"),
    params = Map(
      "access-token" -> "${{ secrets.GITHUB_TOKEN }}"
    )
  )
)

Would there be interest in adding an optional automerge action for scala-steward?

• Could use for example https://github.com/marketplace/actions/merge-me
• There is also Mergify but idk if it can run as a GitHub action

This is the issue @mpilquist promised to file but didn't! ;-)

But tldr, it should be possible to have a sequence of build steps, rather than being hard-coded to just one.

For some odd reason, if you remove a scala version to be tested by CI using githubWorkflowScalaVersions, specifically in my case

// Scala 2.10.7 seems to be causing issues with CI
ThisBuild / githubWorkflowScalaVersions -= "2.10.7"

and I commit this to a PR, githubWorkflowCheck ends up failing (specifically in the ci.yml spot where you have strategy.matrix.scala

You can find an example of this happening here iheartradio/ficus#155, you can check the Continuous Integration / Build and Test (ubuntu-latest, 2.13.6, [email protected]) (pull_request) build failure in that PR.

Hi,

first, thanks for this plugin!
I'm trying to use it for sangria, and the check about ci.yml fails: https://github.com/sangria-graphql/sangria/pull/547/checks?check_run_id=1555592842

info] set current project to sangria-root (in build file:/home/runner/work/sangria/sangria/)
[error] java.lang.RuntimeException: ci.yml does not contain contents that would have been generated by sbt-github-actions; try running githubWorkflowGenerate

Running sbt githubWorkflowGenerate locally does not change this file.
I don't really know how to debug this.

Today there's support for adding both:

• WorkflowJob
• WorkflowStep

...into .github/workflows/ci.yaml

I'm thinking this plugin is so helpful that it could even be used for creating entire Workflow (files). What's your thoughts on this?

fail-fast config missed the last release by a couple of days - can we have a new release please? 🙂

Just like in Use steps, params could be used for adding extra keys to a step, e.g. working-directory.

You can assign to me ;)

Ran in to this on fs2, where the build action runs test in certain sub-projects only. Hence, some subprojects don't have a target directory and the upload fails.

https://github.com/functional-streams-for-scala/fs2/actions/runs/137190325

I initially raised this because Eclipse Temurium has taken over Adoptium - https://adoptium.net/

I then discovered that setup-scala doesn't support Temurin and is no longer being maintained - olafurpg/setup-scala#49

The publish job is failing for me if I use anything other than [email protected] as the Java version for my project.

From the README:

githubWorkflowJavaVersions : Seq[String] – A list of Java versions, using Jabba syntax, which will be used to build your project. Note that the publish job will always run under solely [email protected]. Defaults to [email protected].

Because my project requires Java 11, I have specified this via:

ThisBuild / githubWorkflowJavaVersions := Seq("11")

But this results in the publish job failing, since it assumes artefacts are always published under [email protected].

Either both need to be fixed to [email protected] or both need to be configurable (preferred), no?

Uploads with Java 11:

Downloads with Java 1.8 (and obviously fails in doing so):

Maybe this is out of scope for this library, but I have noticed myself adding WorkflowStep.Sbt(List("scalafmtCheckAll"), name = Some("Check Formatting")) on any projects I have added this plugin to. If this is out of scope, no worries. But if not then I am happy to put up a PR for this!

Hello, im getting OverlappingFileLockException when using CI generated by this plugin. It seems this is happening when SBT compiler bridge is being compiled. Not sure what to do about it :( It's happening pretty consistently. Any ideas what can be done about that pls? :)

Setting an environment variable and prepending to PATH is now done through temporary files, whose names are provided through the environment variables GITHUB_ENV and GITHUB_PATH. Specialized workflow steps for these action would be very convenient.

Since October 2020, the default branch for new repositories is main (instead of master).

It would be good for sbt-github-actions to consider this new behaviour. Not sure if it would be better to replace the current behaviour (make main as default) or to add main as a new valid branch name (both main and master will be the default).

The default JDK changed from 8 to 11 in 0.14.0, which isn't noted in the changelog and probably not what most people want. Lots of people are getting Scala Steward upgrades to sbt-spiewak-0.23 and ending up on Temurin 11, and probably not realizing it.

Could be grate if you would give the configuration for an execution matrix also for the publish step of the CI.
In my particular case i've to build 3 different jar for each OS (win, linux and mac) and publish them to github artifacts, since with the current config I can't do that.

Opening this as a general signal that it doesn't work yet, and an even more general invitation for people to complain and explain how they want it to work. I'll fix it as soon as someone needs this feature.

Arguably, people shouldn't be doing this, but they do (myself included) and it's honestly something that should work. Currently, the target aggregation hack bypasses project aggregates, meaning that we see targets that we theoretically shouldn't.