-
-
Notifications
You must be signed in to change notification settings - Fork 768
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
CircleCI Integration #1479
CircleCI Integration #1479
Conversation
1 similar comment
sorry, no idea. this change smells a bit like the YAML vs JSON vs JS issue for me. Personally, I don't really care as long as it works, as it's just too little time saved to care, but remind me again why you are doing this; aren't these things pretty much the same? |
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.
As @fatso83 commented, are there any special reasons for doing this?
TravisCI has always worked well for me and it has great integration with many services. Have we been having any problems with it lately? Sometimes it could be easier to get in touch with their support and see if these problems can be solved so that we don't have to change infrastructure.
I'm not invalidating these changes, I think you've done great work with all this infrastructure changes, I just wanted to make sure we will avoid unnecessary work.
When it comes to why this test is failing, I've done a quick research and I think it might be because circleCI is trying to do cross-domain XHR. This StackOverflow answer might help you.
It has nothing to do with the config file itself to my knowledge.
I just looked into, because of the problems with running tests in Node 8 on travis. I prefer CircleCI and that's what I've used professionally. I have yet to see an integration that Travis has over Circle. I'm just putting it out there as an option. I also like that it reports each node version individually instead of as a set. Thus you don't have to click through to see where the failures are.
Check out the actual build. It's running phantomic with that option: browserify --no-commondir --full-paths -p [ mocaccino -R spec --color ] test/webworker/webworker-support-assessment.js | phantomic --web-security false |
Node images default to Debian
I didn't mean it was a config issue; I meant it was a superficial change that is functionally equivalent. As long as it works and doesn't make things harder it's all fine to me 😁
Which ones are that? I don't know of any. Superficially googled and came up with this, which seems to be a solved problem. |
Sorry, I am an idiot. Just saw the list of PRs ... #1469, of course. |
Two thoughts:
|
This issue is what made me think of it, btw. Might not be related, but could be. |
We should probably make it a priortiy to replace PhantomJS with headless chrome (#1405). We are likely to do this soon anyway, and it is likely to obviate many of these problems. |
While researching #1498, I understood what the failing synchronous network request was. It simply happens because I'll try to get this fixed as part of my #1498 fixes. |
The WebWorker test in PR sinonjs#1479 seems to fail for some mysterious reason with a synchronous XHR requests. The reason was most probably the importScript('../../pkg/sinon.js') call in the webworker file was referencing a build file that wasn't built. By now explicitly building this file as part of the test run this error has now disappeared locally, and probably will disappear on CircleCI as well.
The WebWorker test in PR sinonjs#1479 seems to fail for some mysterious reason with a synchronous XHR requests. The reason was most probably the importScript('../../pkg/sinon.js') call in the webworker file was referencing a build file that wasn't built. By now explicitly building this file as part of the test run this error has now disappeared locally, and probably will disappear on CircleCI as well.
This should work as soon as #1504 lands. |
Thanks for looking into this! |
The WebWorker test in PR sinonjs#1479 seems to fail for some mysterious reason with a synchronous XHR requests. The reason was most probably the importScript('../../pkg/sinon.js') call in the webworker file was referencing a build file that wasn't built. By now explicitly building this file as part of the test run this error has now disappeared locally, and probably will disappear on CircleCI as well. fixes the build in sinonjs#1479
The WebWorker test in PR sinonjs#1479 seems to fail for some mysterious reason with a synchronous XHR requests. The reason was most probably the importScript('../../pkg/sinon.js') call in the webworker file was referencing a build file that wasn't built. By now explicitly building this file as part of the test run this error has now disappeared locally, and probably will disappear on CircleCI as well. fixes the build in sinonjs#1479
The WebWorker test in PR sinonjs#1479 seems to fail for some mysterious reason with a synchronous XHR requests. The reason was most probably the importScript('../../pkg/sinon.js') call in the webworker file was referencing a build file that wasn't built. By now explicitly building this file as part of the test run this error has now disappeared locally, and probably will disappear on CircleCI as well. fixes the build in sinonjs#1479
No idea why you are getting
|
Hi, this has been building for quite a while. Any reason not to merge it (except for the history 😛 )? For some reason, it is already being used in other PRs here, even though it hasn't been merged to |
Squashed and merged. Thanks, Phred! |
The WebWorker test in PR sinonjs#1479 seems to fail for some mysterious reason with a synchronous XHR requests. The reason was most probably the importScript('../../pkg/sinon.js') call in the webworker file was referencing a build file that wasn't built. By now explicitly building this file as part of the test run this error has now disappeared locally, and probably will disappear on CircleCI as well. fixes the build in sinonjs#1479
Uses alpine docker image (Node images default to Debian)
I'm working on the CircleCI integration to potentially replace TravisCI. So far, the problem I'm having is I don't understand why the
webworker
test (test-webworker
) is failing on Node 6 and 8. FYI it's not run on Node 4. I mostly copied the logic of the travis config into circle.Notes: I'm using their new fancy 2.0 configuration which is new to me.
@sinonjs/sinon-core Any ideas? I can't reproduce locally and I don't see anything out of the ordinary. Is there a way to get any more feedback from the failure?