[dev] Moving to Github Actions for our CI/CD

[Tomaz Muraus <to...@apache.org>]

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.

Re: [dev] Moving to Github Actions for our CI/CD

[anthony shaw <an...@gmail.com>]

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.
>

Re: [dev] Moving to Github Actions for our CI/CD

[Eric Johnson <er...@apache.org>]

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.
>