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
When you define an sbt step in sbt-gh-actions, it automatically prefixes the step with e.g. ++2.13.7 to set the Scala version as defined in the matrix.
When a matrix is split on platform (JVM/JS/Native), it would be helpful to have a step prefixed with e.g. project rootJVM or project rootJS with whatever is defined in the matrix.
I think this is possible, something like this: just as we have axes for OSes, JVMs, and Scala versions in the matrix, we need an axis of "aggregate projects". Each aggregate project would select a slice of sub-projects in the build (e.g., JVM ones or JS ones) and scope all the sbt steps in the workflow to that project, just like they are scoped to a particular Scala version.
I think this might also fix sbt-gh-actions' interop with sbt-project-matrix, which creates one sub-project per Scala version and thus wreaks havoc.
When you define an sbt step in sbt-gh-actions, it automatically prefixes the step with e.g.
++2.13.7
to set the Scala version as defined in the matrix.When a matrix is split on platform (JVM/JS/Native), it would be helpful to have a step prefixed with e.g.
project rootJVM
orproject rootJS
with whatever is defined in the matrix.I think this is possible, something like this: just as we have axes for OSes, JVMs, and Scala versions in the matrix, we need an axis of "aggregate projects". Each aggregate project would select a slice of sub-projects in the build (e.g., JVM ones or JS ones) and scope all the sbt steps in the workflow to that project, just like they are scoped to a particular Scala version.
I think this might also fix sbt-gh-actions' interop with sbt-project-matrix, which creates one sub-project per Scala version and thus wreaks havoc.
Linking to #18.
The text was updated successfully, but these errors were encountered: