Add a workflow to trigger CI jobs

[youknowriad]

Try adding a workflow to see if it can be a replacement for travis.

[youknowriad]

Ok I followed the docs, but how am I supposed to test this workflow?

[senadir]

I think the best way to test is having a fork, not directly pushing to the official version, then we can reference that fork here

[noisysocks]

I think the best way to test is having a fork, not directly pushing to the official version, then we can reference that fork here

The problem is that the forked repo won't have access to the GitHub Actions beta.

[noisysocks]

Everything under steps: needs to be indented by 2 spaces.

[noisysocks]

Looks good but I don't think that we should be replacing Travis just yet. Per the docs:

GitHub Actions is currently in limited public beta and is subject to change. We strongly recommend that you do not use this feature for high-value workflows and content during the beta period.

If you wanted to just try it I'd be happy for you to merge this PR, test it, and then revert the PR 😀

Something I noticed is that you can specify job dependencies so that some jobs don't run until others finish. I'd be interested to try having three jobs:

• install: Runs npm ci
• lint: Runs npm run lint, depends on install
• test: Runs npm test, depends on install

Very curious to find out if all that Microsoft money makes Actions faster than Travis! 😇

[ntwb]

Something I noticed is that you can specify job dependencies so that some jobs don't run until others finish. I'd be interested to try having three jobs:

• install: Runs npm ci
• lint: Runs npm run lint, depends on install
• test: Runs npm test, depends on install

Very similar to Travis CI stages, but at the moment the time it takes to spin up the Docker'ish builds of ~180 seconds needs to be accounted for in the total time for a build.

So, for example, if the install job takes 3 minutes, then the lint job takes 4 minutes, then the test jobs do not start spinning up for at least 7 minutes, and each test job then takes an additional 3 minutes to set up internally, this equates to the test jobs test tasks not actually beginning to be executed until around the ~17 minute mark of the CI build, finally another ~7 minutes to finish the test jobs and the CI build around ~24 minutes.

The above times are rough guesstimates based on current CI job times.

Comparing the above scenario to the current Travis CI job concurrency we have of 15 concurrent jobs for the entire Gutenberg CI build and all jobs are completed in ~15 minutes.

Very curious to find out if all that Microsoft money makes Actions faster than Travis!

Actions comes with 20 concurrent jobs per repo so if the CPU and Memory outperform Travis CI and/or the current test jobs be further split to utilize the extra 5 concurrent jobs CI build time may be reduced without having to use job dependencies (stages).

[senadir]

it seems that for some reason, Action flooded my email with notifications, about 5 for a single PR #16982, not sure why just this PR and not other ones (I have other PRs after it) and why 5.

this should be taken into consideration for future implementation so it can be disabled by default until we reduce the jobs to 1

[talldan]

@senadir Yep, I updated Gutenberg to use the new version of actions today and this happened. It looks like you can change your notifications in github's settings:

[gziolo]

Suddenly there is now only Travis listed in checks section:

🤔

[youknowriad]

I think I'm going to close this PR because I don't have enough time to push it forward. Feel free to take over.