You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make SBT the source of truth for the Github Actions matrix of Scala versions, etc.
A DSL for defining your entire workflow from within your SBT build
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.
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.
The text was updated successfully, but these errors were encountered:
This plugin has three functions:
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.The text was updated successfully, but these errors were encountered: