Works for me. I have no vendor lock-in concerns. :) The only question I have is about Beta status and what that means. In GCP, a Beta service means feature-complete and no breaking changes when the service moves to GA. But Beta has no SLAs. I don't know how GitHub/MS define Beta, nor what their timeline would be to get to GA. But I suppose reverting back to Travis is always an option if necessary.
+1 from me On Wed, Aug 14, 2019 at 5:35 AM Tomaz Muraus <to...@apache.org> wrote: > Everyone, > > Github recently announced Github Actions powered CI/CD platform ( > https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/). > > To see how it works out, I tried porting our existing Travis CI based CI/CD > workflow to Github Actions one - > https://github.com/apache/libcloud/pull/1341. > > Actions CI/CD is still in beta, but I was already fairly happy with the end > result. > > To decrease the barrier to entry and contribution and reduce overhead for > the committers, we already moved all the development to Github recently. > > I think utilizing Actions CI/CD would help us with that as well, since it's > directly integrated into Github (unlike Travis CI). > > Similar to Travis CI, Github Actions CI/CD is also free for open source > project. In addition to that, it currently has much faster build times due > to much shorter build queue and wait times. > > This may change in the future when the platform is out of beta and when > more project starting using it. > > Right now it works out of the box for us, only limitation is we can't > trigger ReadTheDocs build as part of our CI/CD workflow, because we don't > have access to manage Github project secrets (see the corresponding ASF > infra issue for details - > https://issues.apache.org/jira/browse/INFRA-18874 > ). > > What do others think? > > I know there may be some concerns with "vendor lock-in" and putting all the > eggs in a single basket approach, but that can be part of a broader > discussion. > > On one hand, after the MS acquisition, I think Github introduced a lot of > cool and useful new features, but on the other hand I'm also a bit worried > about that general direction since it's making the whole software > development process even more centralized and centered around Github. >
