test(e2e): Set up fake registry for E2E tests#5806
Conversation
AbhiPrasad
left a comment
AbhiPrasad
left a comment
There was a problem hiding this comment.
Cool - @priscilawebdev helps maintain Verdaccio 😄
Reminder, I'd like us to use a recipe system similar to: https://github.com/getsentry/sentry-electron/tree/master/test#end-to-end-tests
| @@ -0,0 +1,27 @@ | |||
| #!/bin/sh | |||
| set -e | |||
There was a problem hiding this comment.
let's make this a node script so we stay windows friendly before we dive deeper into bash land
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
lforst
changed the title
| packageTarballPaths.forEach(tarballPath => { | ||
| // For some reason the auth token must be in the .npmrc, for some reason the npm `--userconfig` flag doesn't always work, | ||
| // and for some reason the registry must be passed via `--registry` AND in the .npmrc because different npm versions | ||
| // apparently work different and we want it to work with different npm versions because of local development. |
There was a problem hiding this comment.
m: A single npm version should be enforced if people are using the node version set in package.json - let’s just remove that inconsistency
There was a problem hiding this comment.
What if we wanna run the e2e tests with different node versions?
There was a problem hiding this comment.
Feels weird though since this is essentially the setup code. Could we make a dockerfile and throw this in there? Thus we can run the actual tests with different node versions, but the setup will always be with the same one.
There was a problem hiding this comment.
Ah now I get it. Yeah I'll take a look. Dockerfile sounds good.
|
Nice!!! 🚀 |
size-limit report 📦
|
| // Publish built packages to the fake registry | ||
| packageTarballPaths.forEach(tarballPath => { | ||
| // `--userconfig` flag needs to be before `publish` | ||
| childProcess.execSync(`npm --userconfig ${__dirname}/test-registry.npmrc publish ${tarballPath}`, { |
Check warning
Code scanning / CodeQL
Shell command built from environment values
| // Publish built packages to the fake registry | ||
| packageTarballPaths.forEach(tarballPath => { | ||
| // `--userconfig` flag needs to be before `publish` | ||
| childProcess.execSync(`npm --userconfig ${__dirname}/test-registry.npmrc publish ${tarballPath}`, { |
There was a problem hiding this comment.
would be nice to just use craft here (https://github.com/getsentry/craft/blob/master/src/targets/npm.ts#L160), but doesn't support custom user configs so we can stick with this.
|
|
||
| // Run container that uploads our packages to fake registry | ||
| childProcess.execSync( | ||
| `docker run --rm -v ${repositoryRoot}:/sentry-javascript --network host ${PUBLISH_PACKAGES_DOCKER_IMAGE_NAME}`, |
Check warning
Code scanning / CodeQL
Shell command built from environment values
4 participants
Ref: #5506
This PR adds an initial setup for E2E tests by adding a script that launches a fake test registry (Verdaccio) and uploads our packages to that test registry.
Besides Verdaccio we also evaluated using yalc. I decided against yalc and in favor of Verdaccio because Verdaccio simulates better what users will do and therefore is what we want to test with these E2E tests:
package.json.The Babel and React projects are also using Verdaccio to conduct their E2E tests, which gave me even more confidence in my choice. The Verdaccio docs even have a section on E2E tests: https://verdaccio.org/docs/e2e/
There are some nitty-gritty details in the
run.tsscript. I tried to explain them all via comments. While reviewing please point out if anything still looks fishy and I'll add some more comments!In a next step, we should extend the test script to actually launch integration tests.