add scala-steward workflow #2218
Conversation
| - name: Launch Scala Steward | ||
| uses: scala-steward-org/scala-steward-action@v2 | ||
| with: | ||
| author-name: scala-steward |
There was a problem hiding this comment.
so this is ignored and we always end up with github-actions? Would be nice to somehow distinguish commits coming from scala-steward, though. I'm afraid there might be other instances of automatic commits coming from the github-actions author, which might end up inadvertendly being merged. But maybe since the mergify config explicitly mentiones the files, it's not a problem
There was a problem hiding this comment.
author-name/email: scala-stuardis used as a commit authorgithub-actionsis used as a user, who opened a PR- it is possible to distinguish PRs created by scala-stuard from inside the CI workflow (using some specific conditions) only the trouble is that the PR workflow is not triggered at all (even with no conditions inside the workflow)
- when I manually close and reopen the PR then the CI workflow is triggered successfully (in this case I'm represented as the PR reopener)
There was a problem hiding this comment.
My proposal for the followup:
- merge the scala-steward action without supporting mergify (scala-steward generates PRs properly, they just need to be accepted by hand); maybe with lower frequency (e.g. once a week?)
- open another issue to debug the problem with workflows not triggered (if solved then add mergify to scala-steward)
- create another issue to simplify (remove duplications) from CI workflow definitions (it's possible to extract common actions like sbt setup/cleanup)
There was a problem hiding this comment.
ah ... so we cannot change the user who is opening the PR?
maybe it's a matter of clicking "allow workflow to run" until the first PR from github-actions is merged?
There was a problem hiding this comment.
I'm fine with merging this without mergify and fixing it in the next PR :)
There was a problem hiding this comment.
but the frequency of once-per-day is fine :)
| {groupId = "org.scala-sbt"}, | ||
| {groupId = "org.scala-lang", artifactId = "scala-compiler", version = "2.12."}, | ||
| {groupId = "org.scala-lang", artifactId = "scala-compiler", version = "2.13."}, | ||
| {groupId = "org.scala-lang", artifactId = "scala-compiler", version = "3."} |
There was a problem hiding this comment.
hm don't we want scala version upgrades?
There was a problem hiding this comment.
With this configuration each Scala "major" version (2.12, 2.13, 3) still gets upgraded within given "major" version (e.g.: 2.12.14 -> 2.12.15) but "major" versions are not changed.
Without this configuration "major" versions also get changed: 2.12.15 -> 2.13.8, 2.13.8 -> 3.1.2)
In result you get:
val scala2_12 = "2.13.8"
val scala2_13 = "2.13.8"
Closes #2183
scala-stewardtriggers on schedulescala-stewardcreates proper PRsmergifydoes NOT merge created PRsscala-stewardsomehow don't trigger the CI workflow which is a required condition formergify. (Unfortunately I was unable to figure out a solution for this problem in given time.)