Skip to content

CI: introduce github actions #31017

Closed
Closed

Description

@gengjiawen

We already has travis-CI for basic CI, why introduce another one ?

There are a few reasons.

  • Github actions has better github integrations. Travis CI has to be enabled by project maintainer.Like https://github.com/nodejs/quic, you have to go to travis website to make it work, orgnization members won't has the permission. If we has this, futher experimental projects CI part should be easy.

  • Github action support linux, macOS, windows. I am thinking introduce build steps on all three platforms. This should make build problem found more early. (Like quic: initial experimental quic implementation #30943, works on linux, but not on macOS). Maybe only execute test on one platform.

  • Github action machine config is good than others, macOS has

  System:
    OS: macOS 10.15.1
    CPU: (4) x64 Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz
    Memory: 8.21 GB / 12.00 GB

We already has Github actions in https://github.com/cjihrig/uvwasi and https://github.com/nodejs/node-gyp.

Even if we decide to maintain travis and github actions simultaneously (which is very common), still worth it.

cc @nodejs/build @cclauss

Activity

  1. mscdex commented on Dec 18, 2019

    @mscdex
    Contributor

    There was this previous PR FWIW.

  2. MylesBorins commented on Dec 18, 2019

    @MylesBorins
    Contributor

    One thing I have not seen solved via github actions is a good way at looking at the output of a test suite. Is there a decent solution from that aside from digging through the logs?

  3. cclauss commented on Dec 19, 2019

    @cclauss
    Contributor

    In Actions output, each build step is below a twisty and only build steps that have failed have their twisty open. So if you create lots of job step then there is no digging required to find the failure.

  4. gengjiawen commented on Dec 19, 2019

    @gengjiawen
    MemberAuthor

    @cclauss Any thought on reopen your PR ?

  5. cclauss commented on Dec 19, 2019

    @cclauss
    Contributor
  6. gengjiawen commented on Dec 19, 2019

    @gengjiawen
    MemberAuthor

    Thought on make one of the PRs support windows and macOS too ?

  7. cclauss commented on Dec 19, 2019

    @cclauss
    Contributor

    Sure. Go for it.

  8. richardlau commented on Dec 19, 2019

    @richardlau
    Member

    I'm broadly in favour of trying things on GitHub actions.

    A couple of concerns:

    • We're going further away from the quite simple "check if the Node.js CI run is not red" before landing to potential confusion as to what has to pass in order to land a PR (I've seen confusion over Travis CI results, which up until recently were only considered advisory). Perhaps a solution is node-core-utils but that currently (a) does not look at the results of Node.js CI runs (it just checks one has been run) and (b) doesn't currenly check anything other than Node.js CI runs.
    • Maintenance. The CI jobs (on any of the providers) have an ongoing people maintenance cost. For the Node.js CI that is (the overstretched) @nodejs/build. I and a few others have kept Travis CI working for us (I used to manually restart a lot of Travis CI jobs). Actions are relatively new so will need contributors to step up to keep it working (on the other hand if we can move things from Node.js CI into actions and reduce the burden on @nodejs/build that would be a plus).
  9. sam-github commented on Dec 19, 2019

    @sam-github
    Contributor

    node-core-utils but that currently (a) does not look at the results of Node.js CI runs (it just checks one has been run)

    I had never noticed that! In retrospect, its because I don't even try to run git node land until it is green.

  10. gengjiawen commented on Jan 2, 2020

    @gengjiawen
    MemberAuthor

    Maintenance.

    I would like to be involved maintain github action. Feel free to @ me when there is related issue.

  11. gengjiawen commented on Jan 2, 2020

    @gengjiawen
    MemberAuthor

    My intention is only to try build tasks. So I opened a new PR: #31153.

  12. cclauss commented on Jan 2, 2020

    @cclauss
    Contributor

    Also open are #29474 and #29193

  13. gengjiawen commented on Jan 10, 2020

    @gengjiawen
    MemberAuthor

    close for #31153 is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions