It looks really similar to Azure Pipelines (and the syntax looks similar)..
Makes you wonder if its the same platform?

Anyway, I'm not tied to Travis CI. It's been stable, but we only test on
Linux.

There would be benefits to having a consolidated Windows/Linux testing
matrix.

In some of my personal projects, I've started adding packaging and
installation to the test phases, which is really tricky to do with Travis.

Tomaz, I know you've done similar things with Circle. But personally, I
find Circle slow and complicated :-)

+1 from me

On Wed, Aug 14, 2019 at 2:35 PM 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.
>

Reply via email to