-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fix(test): test:client
silently failing on Travis
#3343
Conversation
test:client
silently failing on Travistest:client
silently failing on Travis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The top of this file says
THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
We can't have the core files blocked by downstream issues. So what change in this project would update natives?
The warning is to prevent people from breaking lock file by incorrect edits. The change does exactly what it is supposed to: makes Yarn resolve In fact this change was done by removing |
Ok but this file is a product of some other config which needs to be fixed or we'll just overwrite it. And we don't even use yarn AFAIK, so I don't understand how this is relevant, except to someone who uses yarn install I suppose. |
This is not completely true. While See https://yarnpkg.com/en/docs/yarn-lock#toc-check-into-source-control for more information:
Yarn is used on Travis builds (https://docs.travis-ci.com/user/languages/javascript-with-nodejs#using-yarn) and I believe some developers use it for local development. It is not used and does not affect end users of the Karma. If you think that this repo should stop using Yarn completely then we should remove |
If our tests must be run against natives 1.1.6, then shouldn't we add a dependency on natives ^1.1.6 to package.json? Then the yarn.lock will work on travis and won't slide back if we run |
It comes from the following dependencies chain: |
But this makes yarn.lock an output, a build result. It's the result of version resolution, not the definition of versions. If I delete yarn.lock and redo the version resolution I'll get a valid yarn.lock a lot of changes. Will I notice that natives slid back to 1.1.1? Is there a reason not to dep natives 1.1.6 in the package.json with a comment that we want to fix the downstream chain? I gather that graceful-fs only needs natives ^1.1.1, except on node 10 where it needs ^1.1.3. So its the broken package. |
Based on your analysis I create PR #3344, do you think it could achieve your goal? |
Yes, this solution is much better! |
Apparently it is not enough to check `code`, because when process crashes `code` is set to `null` and `err` is passed instead. Example of failing tests, which didn't fail build: https://travis-ci.org/karma-runner/karma/jobs/537027667#L1046
Thanks! |
It is not enough to check exit
code
, because when process crashescode
is set tonull
anderr
is passed instead. Adjusted build script accordingly and forced new version ofnatives
to make tests pass.Example of failing tests, which didn't fail build:
https://travis-ci.org/karma-runner/karma/jobs/537027667#L1046