Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to GitHub Actions CI #1600

Merged
merged 11 commits into from Dec 28, 2020
Merged

Switch to GitHub Actions CI #1600

merged 11 commits into from Dec 28, 2020

Conversation

XhmikosR
Copy link
Contributor

@XhmikosR XhmikosR commented Dec 26, 2020

It seems there are a few issues:

  1. .travis.yml was using make travis-test but that was using @npm run test:lint which doesn't exist; I changed it to @npm run lint but the makefile isn't up to date. EDIT: I switched to npm test but IMHO the Makefile should be removed to avoid confusion since it's clearly broken
  2. it seems make travis-test is failing; test-cov also doesn't seem to work. Happy to sort everything out as long as you give me some hints. My suggestion is to move everything to npm scripts only and Actions including coverage.
  3. I added another job with BENCHMARK=true
  4. We can add further Node.js versions, OS etc. Let me know and I can take a stab at it later. I'd just split lint to a separate action or job and run it only once.

Notes:

  1. since Actions don't currently support LTS tags, I explicitly set this to 14 in an env var
  2. I added npm caching which is what Travis CI was doing by default

EDIT: it seems that npm test didn't even run on Travis CI hence why the failures weren't caught sooner.

This was referenced Dec 27, 2020
@XhmikosR
Copy link
Contributor Author

XhmikosR commented Dec 27, 2020

I decided to split the actions so that lint and tests are done faster. So, things that remain:

  1. should we get rid of Makefile completely? I vote for yes since it's outdated and confusing to keep the build scripts in two places
  2. should I add more Node.js versions in tests? If so, which ones? EDIT: added 10, 12 and 15; less than 10 fails due to mocha requiring 10
  3. should I add more OS'es in tests? If so, which ones and in which tests?
  4. should I add the ability to skip bench if the commit message includes [skip bench] or something like that? EDIT: added this

@fb55
Copy link
Member

fb55 commented Dec 27, 2020

Tests should be fixed with #1596

@XhmikosR
Copy link
Contributor Author

XhmikosR commented Dec 28, 2020

@fb55 so, how do you think we should proceed with the remaining TODOs? Also, is there something you want me to change?

Copy link
Member

@fb55 fb55 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. Added some questions.

on:
push:
branches-ignore:
- 'dependabot/**'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we still run tests for Dependabot PRs with this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, since depndabot always opens a PR, this just skips the branches.


- name: Run Jest with coverage
run: npm run test:jest:cov
if: matrix.node == 14
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to move this to an env var, so that there is only a single reference to the Node version used for coverage?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do, how do you want to name the env var? Also, do you want the env var to be in the global scope or under the job?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pattern in the site action is great, maybe just copy that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, it's just that it might not be self-explanatory using NODE, but I can add a comment.

Also, we could just run jest with --coverage regardless of the Node version, and just run coveralls only on Node.js 14. That would be less lines.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Saw you changed the name to NODE_COV, which should be easy enough to distinguish.

we could just run jest with --coverage regardless of the Node version

I like that idea as well. But the current slight duplication isn't too bad either 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your call. There isn't so much of a difference, just 3 seconds. I'll leave it as is and you can change it later if needed.

@@ -12,7 +17,15 @@ jobs:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: 14.x
node-version: '${{ env.NODE }}'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great 👌

<a href="https://travis-ci.org/cheeriojs/cheerio">
<img src="https://img.shields.io/travis/cheeriojs/cheerio/main" alt="Travis CI">
<a href="https://github.com/cheeriojs/cheerio/actions?query=workflow%3ACI+branch%3Amain">
<img src="https://img.shields.io/github/workflow/status/cheeriojs/cheerio/CI/main" alt="Build Status">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should lint and CI be in the same file (as different jobs), to make this cover both? (That's the current behavior, but I can also see a point about having them be separate.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I split the actions is so that everything is faster since they run in parallel this way. I doubt having a badge to lint is something that people should care about :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't separate jobs be executed in parallel as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but I personally find this cleaner. Each workflow does one thing. That being said, the types test could probably be moved to the lint workflow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense & I can live with this.

@XhmikosR XhmikosR marked this pull request as ready for review December 28, 2020 07:12
@fb55
Copy link
Member

fb55 commented Dec 28, 2020

I'm happy to go forward with this. Super excited to see this land.

@XhmikosR The PR is still a draft. Let me know when you feel ready to proceed.

@XhmikosR
Copy link
Contributor Author

I'm still not sure about keeping the Makefile around. It's unnecessary duplication and it seems Makefile has a script that is not present in package.json (xyz).

I'll leave that to you to sort later :)

PS. I'm still being bitten by #1602 since my dev VM is on Windows.

This should allow caches to be shared between workflows.
@fb55 fb55 merged commit b9453ea into cheeriojs:main Dec 28, 2020
@XhmikosR XhmikosR deleted the gh-actions branch December 28, 2020 07:16
@fb55
Copy link
Member

fb55 commented Dec 28, 2020

Good point about the Makefile. Thanks so much for this PR, this moves us forward considerably.

@XhmikosR
Copy link
Contributor Author

@fb55 a few more things to do:

  1. go to the repo apps/integrations/hooks and remove any Travis CI related stuff
  2. adapt any branch protection
  3. go on coveralls and change the threshold for failure to something like 0.5; by default, even a .001 decrease will mark the build as failed

fb55 added a commit that referenced this pull request Dec 28, 2020
fb55 added a commit that referenced this pull request Dec 28, 2020
@5saviahv 5saviahv added the github_actions Pull requests that update Github_actions code label Jan 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
github_actions Pull requests that update Github_actions code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants