-
Notifications
You must be signed in to change notification settings - Fork 272
mock s3 v2 #540
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
mock s3 v2 #540
Changes from all commits
82f2585
3cdf6e5
fd65693
7e67967
b787ad5
e8d23db
6a250af
311348e
ed4c495
f05b0da
cce28fc
65dd24f
3172232
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,8 @@ services: | |
| # have more than one run with the same node version | ||
| # otherwise they will clobber each other | ||
| ##### | ||
| env: | ||
| node_pre_gyp_mock_s3=true | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is great. Even better I think would be another matrix/job so that:
Sound good? If so, could you add another job that uses
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it's easy enough to move the env into the matrix and add the but i'm not sure what you mean by "only the mocking job is with coverage is tested and uploaded". and maybe it's related, but if mocking is false won't all external PR tests always fail? |
||
|
|
||
| matrix: | ||
| include: | ||
|
|
@@ -17,6 +19,7 @@ matrix: | |
| node_js: 10 | ||
| before_install: | ||
| - npm install request | ||
| - npm install --package-lock-only | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've been thinking we should move to
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. actually, the command that is executed further down is npm ci and that fails because package.json and package-lock.json are out of sync. at least that's what i was seeing. that's why only this test was failing - it's the only one that did |
||
| script: | ||
| - npm run lint | ||
| - npm run coverage | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,13 @@ module.exports = exports; | |
| * Module dependencies. | ||
| */ | ||
|
|
||
| // load mocking control function for accessing s3 via https. the function is a noop always returning | ||
| // false if not mocking. | ||
| exports.mockS3Http = require('./util/s3_setup').get_mockS3Http(); | ||
| exports.mockS3Http('on'); | ||
| const mocking = exports.mockS3Http('get'); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you add a little more detail on why this is needed? My question is coming from the deeper question of whether there is any way we could avoid having this code in
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. my original goal (in the original PR) was to not modify any of the code in lib (or as little as possible). but to do so meant modifying the script command in package.json which led to more problems (different env var settings for windows/linux, changes in what program was actually run, etc. - that stuff is still in the other PR if you want to compare). i originally put this here because i am not sure whether but one way or the other the code has to go into
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. and, if not in a couple options: i can make the code slightly less invasive by not requiring that it be turned on. i could also just let the code check the env var again. i didn't because i was trying to localize knowledge of the env var to the single s3_setup module. if i do that it can look like: and if you want to avoid the 'mock' reference it could just be changed to |
||
|
|
||
|
|
||
| const fs = require('fs'); | ||
| const path = require('path'); | ||
| const nopt = require('nopt'); | ||
|
|
@@ -38,6 +45,10 @@ const aliases = {}; | |
| // differentiate node-pre-gyp's logs from npm's | ||
| log.heading = 'node-pre-gyp'; | ||
|
|
||
| if (mocking) { | ||
| log.warn(`mocking s3 to ${process.env.node_pre_gyp_mock_s3}`); | ||
| } | ||
|
|
||
| exports.find = require('./pre-binding').find; | ||
|
|
||
| // | ||
|
|
@@ -287,4 +298,3 @@ Object.defineProperty(proto, 'version', { | |
| }, | ||
| enumerable: true | ||
| }); | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Uh oh!
There was an error while loading. Please reload this page.