Skip to content

test: rework the integration tests to not use docker #4078

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

Merged
merged 1 commit into from
Nov 1, 2021

Conversation

bradzacher
Copy link
Member

@bradzacher bradzacher commented Oct 31, 2021

The integration tests started failing.
I don't know why. I don't understand docker and trying to figure it out was really opaque.
The new version of docker desktop does have a UI - but it is pretty useless unless you PAY for docker...

I tried upgrading the docker image to the node16 image (alpine), but that introduced a different error saying that the shell script was missing - even though my ls showed the file was in the exact place on the container's disk. I spent about an hour trying to debug this - it was all super confusing because I've never properly used docker before.
At this point - I'm kind of done with docker for this.
It seems like overkill anyway considering all we need is a folder isolated from our local node_modules folder.

This PR replaces the docker testing infra with a new pure JS version.
It's a like-for-like change, with the following differences:

  • Instead of using a container to isolate the test - it creates a temporary folder.
  • Instead of packaging and installing our packages locally once per container - it does it once for all tests.
  • Instead of executing shell scripts - it executes commands (yarn install and eslint via node).
  • It uses yarn instead of npm so that installs can use an offline cache (so they are faster).
  • Instead of separately executing jest, it asserts the snapshot as part of the script.
  • Each test is a separate jest test file, which makes it easy to snapshot and execute the test.

Benefits:

  • Much faster than the docker solution - each individual test takes around 9-12s locally.
  • Less opaque for other contributors as there is no docker magic

Downsides:

  • Not truly isolated as it can still be influenced by the local dev environment - I don't think this is a huge deal for ESLint.

@bradzacher bradzacher added the tests anything to do with testing label Oct 31, 2021
@typescript-eslint
Copy link
Contributor

Thanks for the PR, @bradzacher!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!


🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

@codecov

This comment has been minimized.

@nx-cloud
Copy link

nx-cloud bot commented Oct 31, 2021

@bradzacher bradzacher force-pushed the fix-integration-tests branch from ebeaa00 to a5edfe0 Compare October 31, 2021 18:29
The integration tests started failing.
I don't know why. I don't understand docker and trying to figure it out was really opaque.
The new version of docker desktop does have a UI - but it is pretty useless unless you PAY for docker...

I tried upgrading the docker image to the node16 image (alpine), but that introduced a different error saying that the shell script was missing - even though my `ls` showed the file was in the exact place on the container's disk. I spent about an hour trying to debug this - it was all super confusing because I've never properly used docker before.
At this point - I'm kind of done with docker for this.
It seems like overkill anyway considering all we need is a folder isolated from our local `node_modules` folder.

This PR replaces the docker testing infra with a new pure JS version.
It's a like-for-like change, with the following differences:

- Instead of using a container to isolate the test - it creates a temporary folder.
- Instead of packaging and installing our packages locally once per container - it does it once for all tests.
- Instead of executing shell scripts - it executes commands (`yarn install` and `eslint` via node).
- It uses `yarn` instead of `npm` so that installs can use an offline cache (so they are faster).
- Instead of separately executing jest, it asserts the snapshot as part of the script.
- Each test is a separate jest test file, which makes it easy to snapshot and execute the test.

Benefits:
- Much faster than the docker solution - each individual test takes around 9-12s locally.
- Less opaque for other contributors as there is no docker magic

Downsides:
- Not *truly* isolated as it can still be influenced by the local dev environment - I don't think this is a huge deal for ESLint.
@bradzacher bradzacher force-pushed the fix-integration-tests branch from a5edfe0 to 65837a5 Compare October 31, 2021 23:27
@typescript-eslint typescript-eslint deleted a comment from nx-cloud bot Oct 31, 2021
@bradzacher
Copy link
Member Author

merging to fix the CI signal.
we can back it out later if we hate this idea.

@bradzacher bradzacher merged commit 18104cd into master Nov 1, 2021
@bradzacher bradzacher deleted the fix-integration-tests branch November 1, 2021 03:17
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
tests anything to do with testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy