Migrate publishing from Travis/Bintray to GitHub-Actions/Sonatype

[octonato]

The minimal goal for each migration is that a project no longer publishes via Bintray. A project must publish by tag to Sonatype. Ideally, the migration of the CI build includes moving away from whatever CI it currently uses and adopts GitHub Actions.

Current decision is that we will only migrate when there is an immediate need, ie: just before a release. Also, to keep things small and avoid new issues we don't migrate everything to GitHub Actions but only the releasing part (publish to gustav, whitesource and publishing to sonatype).

the fastest way to achieve the minimum (gustav, whitesoiurce, publish to sonatype) is to copy this workflow, adjust it and remove any publish-related job from travis.

• https://github.com/akka/akka-grpc (related to Introduces a build and test GH workflow akka-grpc#1325)
• https://github.com/akka/akka-http (done sonatype)
• https://github.com/akka/akka-paradox
• https://github.com/playframework/playframework (done sonatype)
• https://github.com/playframework/twirl (use latest interplay and run a release)
• https://github.com/playframework/play-json
• https://github.com/playframework/play-slick
• https://github.com/playframework/play-ws
• https://github.com/playframework/play-file-watch
• https://github.com/playframework/cachecontrol
• https://github.com/playframework/omnidoc
• https://github.com/playframework/interplay (done sonatype)
• https://github.com/lagom/lagom (done sonatype)

The following need migrating away from Bintray and are also affected by #150 (migration to GH Actions required to prevent dockerhub rate-limiting issues in Travis)

• https://github.com/akka/akka-management (in progress release to sonatype using GH Actions akka-management#889)
• https://github.com/akka/akka-persistence-jdbc
• https://github.com/akka/akka-persistence-cassandra
• https://github.com/akka/akka-persistence-spanner
• https://github.com/akka/akka-persistence-couchbase
• https://github.com/akka/alpakka (sonatype done, missing GH Actions)
• https://github.com/akka/alpakka-kafka
• https://github.com/akka/akka-projection

[ignasi35]

playframework/interplay (we probably can take the opportunity to retire this one)

I don't think we should pay the cost of that retirement now.

[ihostage]

• https://github.com/playframework/play-soap (moved to Publishing directly to Sonatype playframework/play-soap#246)

[octonato]

@ignasi35, I didn't check them all, but check this https://github.com/playframework/play-ws/blob/master/project/plugins.sbt#L4

Those project do use bintray, either directly or indirectly via interplay. If they are using interplay, I would prefer to step out and just use sbt-ci-release. That's better than having another interplay release just because of that.

[octonato]

@ihostage, would you do the necessary for play-soap?

I can add the necessary keys to Travis.

[ignasi35]

@ignasi35, I didn't check them all, but check this https://github.com/playframework/play-ws/blob/master/project/plugins.sbt#L4

Those project do use bintray, either directly or indirectly via interplay. If they are using interplay, I would prefer to step out and just use sbt-ci-release.

Of course! 🤦🏼‍♂️

There are a handful of projects in the play ecosystem that (1) already moved away from interplay, and (2) used bintray as the staging environment before pushing to sonatype.

That's better than having another interplay release just because of that.

There's no need for another interplay release in any case since latest interplay 2.8.x and 3.0.x already moved away from bintray.

[ignasi35]

BTW, I think whatever effort we put in migrating the reports listed in the description of this issue it should include both master and stable branches!

[octonato]

I'm wondering what could be a quick win strategy here. I think in general we want to move to GH Actions because of the many issues we encounter (and still encounter) with Travis.

A quick path for the bintray issue could be to only move the release to GH Actions for now.

I don't want to move everything to GH Action right now and I don't want to start configure Travis with the credentials for sbt-ci-release and a month later redo it for GH Actions.

In other projects, we the release.yml workflow only works in master after a PR merge or after tagging. It will then publish the artifacts (snapshots or release), run whitesource and then publish docs to gustav.

Bottom line is, we can use GH Actions for the release and Travis for the PR tests.

[ihostage]

@ihostage, would you do the necessary for play-soap?
I can add the necessary keys to Travis.

@octonato Yes, of course. I created a separate issue for Play SOAP (playframework/play-soap#246) and do that when will find time for that.

[ignasi35]

I'm wondering what could be a quick win strategy here.

TBQH, I think the best option is to not migrate anything and just migrate if/when required. Something as simple as migrating to GH Actions is already surfacing issues. See the ongoing efforts for lagom and akka-grpc.

[octonato]

@ignasi35, I updated the description with the conclusion of our discussion.

I will continue with the akka-management anyway because it's suffering from dockerhub rate limiting. All the other projects follow your suggestion to only do when needed.

@ihostage, that doesn't include play-soap. It's up to you when you want to migrate it. Let me know when I need to generate a gpg key for publishing and setup the secrets for you.

[ignasi35]

@octonato we should put akka-persistence-cassandra (and probably all other persistence plugins) on the list to migrate to GH since they use docker on the CI.

[octonato]

we should put akka-persistence-cassandra (and probably all other persistence plugins) on the list to migrate to GH since they use docker on the CI.

Ok, I will change the description. First a list of ASAP must have because of Docker. Those a GH Action and Sonatype.

Then the list of TODOs when we need/time allow.

[mkurz]

Please add play-mailer to the list:

• https://github.com/playframework/play-mailer

[ignasi35]

I have split this issue in two so #149 stays focused on migrating away from Bintray.

#150, OTOH, focuses on migrating away from Travis, specially those jobs that need docker to run.

[ennru]

We're good here.