search

akka / akka-meta

This repository is dedicated to high-level feature discussions and for persisting design decisions.
Apache License 2.0
201 stars 23 forks source link

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

Closed octonato closed 2 years ago

octonato commented 3 years ago

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.

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)

ignasi35 commented 3 years ago

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 commented 3 years ago
octonato commented 3 years ago

@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 commented 3 years ago

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

I can add the necessary keys to Travis.

ignasi35 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 (https://github.com/playframework/play-soap/issues/246) and do that when will find time for that.

ignasi35 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

Please add play-mailer to the list:

ignasi35 commented 3 years ago

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 commented 2 years ago

We're good here.