Proposal: Switch to github actions

[mwz]

I'd like to propose that we switch from Travis to Github actions and set up the following:

• PR checks (Add github PR action #318):
  • run tests against a matrix of Scala versions (similarly to what is currently done in travis) and in addition:
  • publishLocal and execute Scapegoat against itself (and fail on errors) as mentioned in Results of running Scapegoat against Scapegoat #305
  • use codecov to post coverage info
• post coverage info to codecov on master (Add a codecov workflow for master. #323)
• publish snapshots every time a PR is merged to master; sbt-ci-release works like a charm - I've set it up recently for scalastyle here (Add a release workflow. #327)
• automate the release based on a pushed tag (also works great, see the same github action above) (Add a release workflow. #327)

[sksamuel]

I use github actions elsewhere and am very happy with it. See kotest / hoplite

…

On Thu, 12 Mar 2020 at 19:41, Michael Wizner ***@***.***> wrote: I'd like to propose that we switch from Travis to Github actions and set up the following: - PR checks: - run tests against a matrix of Scala versions (similarly to what is currently done in travis) and in addition: - publishLocal and execute Scapegoat against itself (and fail on errors) as mentioned in #305 <#305> - use codecov to post coverage info - publish snapshots every time a PR is merged to master; sbt-ci-release <https://github.com/olafurpg/sbt-ci-release> works like a charm - I've set it up recently for scalastyle here <https://github.com/beautiful-scala/scalastyle/blob/master/.github/workflows/release.yml> - automate the release based on a pushed tag (also works great, see the same github action above) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#306>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGV6TCP5NT67E4PXHRDRHF6KTANCNFSM4LGYESYA> .

[mwz]

hey @mccartney, do you have any thoughts on the above? Are you happy with this approach?

[mccartney]

I am fine. I don't have any experience with Github Actions (happy to learn them though).

I think it's mostly about the publish process, which I don't know how it works for this project.

All in all - go ahead. I have no input here. I appreciate your work!

[sksamuel]

What I've done elsewhere is have a snapshot publish for every commit to master, and leave release publications manual.

…

On Sun, 15 Mar 2020 at 12:12, Greg Oledzki ***@***.***> wrote: I am fine. I don't have any experience with Github Actions (happy to learn them though). I think it's mostly about the publish process, which I don't know how it works for this project. All in all - go ahead. I have no input here. I appreciate your work! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#306 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGWOOEFGQTYUPKULAPTRHUD7BANCNFSM4LGYESYA> .

[mwz]

I'm planning to have the release automated on a tag being pushed, so that any maintainer with push permissions can push a tag and trigger a new release. Hopefully, that can lead to more frequent releases and less strain on you @sksamuel (if you're happy to distribute this effort across maintainers).

[sksamuel]

That would be nice, I've not used sbt-ci-releases. I tend to release all my projects by hand.

…

On Sun, 15 Mar 2020 at 13:01, Michael Wizner ***@***.***> wrote: I'm planning to have the release automated on a tag being pushed, so that any maintainer with push permissions can push a tag and trigger a new release. Hopefully, that can lead to more frequent releases. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#306 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGUNIZVN7AZ2AK4TAQ3RHUJXXANCNFSM4LGYESYA> .