status-im
/
sourcecred
mirror of https://github.com/status-im/sourcecred.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
sourcecred/config/test.js

141 lines
3.2 KiB
JavaScript
Raw Normal View History

Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
// @flow
backend: invoke Webpack directly in package script (#782) Summary: This commit removes the `config/backend.js` script and replaces it with a direct invocation of Webpack. This enables us to use command-line arguments to Webpack, like `--output-path`. Test Plan: Note that `rm -rf bin; yarn backend` still works, and that the resulting applications work (`node bin/sourcecred.js load`). Note that `yarn test` and `yarn test --full` still work. wchargin-branch: backend-webpack-direct
2018-09-05 19:28:27 +00:00
const tmp = require("tmp");
Make `execDependencyGraph` a CommonJS module (#767) Summary: This simplifies interfaces everywhere. See also #216, which did the opposite of this as a temporary fix due to a Babel/Webpack interaction that no longer exists as of #766. Test Plan: Note that `node bin/sourcecred.js load sourcecred/example-git` still works (after `yarn backend`). Note that `yarn test` still works. These demonstrate that the module works from both a Webpack context and a Node context. Note that `git grep --name-only execDependencyGraph` yields exactly those files touched in this commit. Note that `yarn test --full` passes. wchargin-branch: commonjs-execDependencyGraph
2018-09-05 05:01:22 +00:00
const execDependencyGraph = require("../src/tools/execDependencyGraph");
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
Extract `execDependencyGraph` core from CI script (#208) Summary: We’d like to use the same abstraction for creating multiple cred graphs and then combining them together. This will enable us to do that. Test Plan: Run `yarn travis` to test the success case, and `yarn travis --full` (without setting a `GITHUB_TOKEN`) to test the failure case. wchargin-branch: execdepgraph
2018-05-04 22:47:26 +00:00
main();
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
function main() {
test: validate arguments (#980) Summary: Prior to this commit, running `yarn test full` (instead of `--full`) would silently behave the same way as `yarn test`. This is misleading. It now fails. Test Plan: Run `! yarn test full && yarn test --full`. wchargin-branch: test-validate-arguments
2018-11-01 18:34:13 +00:00
const options = parseArgs();
Make `yarn test` more quiet (#1037) This commit adds a new runOption for execDependencyGraph, namely `printVerboseResults`. If this flag is true, then execDependencyGraph will print a "Full Results" section along with the standard error and standard out of every task, regardless of whether it failed or succeeded. (Note, this is the existing behavior for all invocations prior to this commit). If the flag is not true, then execDependencyGraph will not print a full results section, and stdout/stderr will be logged only for tasks that fail. This commit also modifies `yarn test` to use the new flag so that it prints verbose tests only when the `--full` option is provided. This is consistent with our sharness behavior: we print the full sharness logs only when `--full` was provided. This fixes #1035, and ensures that running `yarn test` has a high signal to noise ratio (i.e. it only shows an enumeration of top level tasks). This improves the developer ergonomics of SourceCred by not having a super commonly used and core script spam the user with mostly irrelevant information. Test plan: Run `yarn test` when all tests are passing, and observe that the output has much less noise: ``` yarn run v1.12.3 $ node ./config/test.js tmpdir for backend output: /tmp/sourcecred-test-6337SZ9smvWsWvqE Starting tasks GO ensure-flow-typing GO check-stopships GO check-pretty GO lint GO flow GO unit GO backend PASS check-stopships PASS ensure-flow-typing PASS flow PASS backend GO sharness PASS sharness PASS check-pretty PASS lint PASS unit Overview Final result: SUCCESS Done in 11.66s. ``` Run `yarn test` when there is a real failure (e.g. a unit test failure) and observe that full details on the failure, including the output from stdout/stderr, is still provided. Run `yarn test --full` and observe that full, verbose logs are provided.
2019-01-06 02:16:29 +00:00
const printVerboseResults = options.mode === "FULL";
const runOptions = {printVerboseResults};
const tasks = makeTasks(options.mode);
execDependencyGraph(tasks, runOptions).then(({success}) => {
Extract `execDependencyGraph` core from CI script (#208) Summary: We’d like to use the same abstraction for creating multiple cred graphs and then combining them together. This will enable us to do that. Test Plan: Run `yarn travis` to test the success case, and `yarn travis --full` (without setting a `GITHUB_TOKEN`) to test the failure case. wchargin-branch: execdepgraph
2018-05-04 22:47:26 +00:00
process.exitCode = success ? 0 : 1;
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
});
}
test: validate arguments (#980) Summary: Prior to this commit, running `yarn test full` (instead of `--full`) would silently behave the same way as `yarn test`. This is misleading. It now fails. Test Plan: Run `! yarn test full && yarn test --full`. wchargin-branch: test-validate-arguments
2018-11-01 18:34:13 +00:00
function parseArgs() {
const options = {mode: "BASIC"};
const args = process.argv.slice(2);
for (const arg of args) {
if (arg === "--full") {
options.mode = "FULL";
} else {
throw new Error("unknown argument: " + JSON.stringify(arg));
}
}
return options;
}
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
function makeTasks(mode /*: "BASIC" | "FULL" */) {
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
const backendOutput = tmp.dirSync({
unsafeCleanup: true,
prefix: "sourcecred-test-",
}).name;
console.log("tmpdir for backend output: " + backendOutput);
function withSourcecredBinEnv(
invocation /*: $ReadOnlyArray<string> */
) /*: string[] */ {
return ["env", "SOURCECRED_BIN=" + backendOutput, ...invocation];
}
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
const basicTasks = [
Ensure that flow is used in all js files (#232) This script ensures that either //@flow or //@no-flow is present in every js file. Every existing js file that would fail this check has been given //@no-flow, we should work to remove all of these in the future. Test plan: I verified that `yarn travis` fails before fixing the other js files, and passes afterwards.
2018-05-08 03:02:19 +00:00
{
id: "ensure-flow-typing",
cmd: ["./scripts/ensure-flow.sh"],
deps: [],
Check for STOPSHIPs in CI (#301) Summary: Placing `STOPSHIP` or `stopship` (or any case variant) in any file tracked by Git will now cause a `yarn travis` failure. If you need to use this string, you can concatenate it as `"stop" + "ship"` or equivalent. Test Plan: In `travis.js`, change `"check-stop" + "ships"` to `"check-stopships"`, and note that this causes the build to fail with a nice message. Note that this also causes `check-stopships.sh` to fail even when invoked from an unrelated directory, like `src`. wchargin-branch: check-stopships
2018-05-26 02:27:31 +00:00
},
{
// eslint-disable-next-line no-useless-concat
id: "check-stop" + "ships",
// eslint-disable-next-line no-useless-concat
cmd: ["./scripts/check-stop" + "ships.sh"],
deps: [],
Ensure that flow is used in all js files (#232) This script ensures that either //@flow or //@no-flow is present in every js file. Every existing js file that would fail this check has been given //@no-flow, we should work to remove all of these in the future. Test plan: I verified that `yarn travis` fails before fixing the other js files, and passes afterwards.
2018-05-08 03:02:19 +00:00
},
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
{
id: "check-pretty",
Tests use yarn not npm (#1038) Currently, our underlying test script uses npm rather than yarn to execute the tests. This is awkward, because we use yarn everywhere else in lieu of npm. It turns out that some setups have node available without npm, and in such environments our tests fail with a cryptic ENOENT error. This changes the tests to use yarn instead. Test plan: `yarn test --full` passes. Thanks to @wpank for help uncovering this issue.
2019-01-07 22:38:21 +00:00
cmd: ["yarn", "run", "--silent", "check-pretty"],
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
deps: [],
},
{
id: "lint",
Tests use yarn not npm (#1038) Currently, our underlying test script uses npm rather than yarn to execute the tests. This is awkward, because we use yarn everywhere else in lieu of npm. It turns out that some setups have node available without npm, and in such environments our tests fail with a cryptic ENOENT error. This changes the tests to use yarn instead. Test plan: `yarn test --full` passes. Thanks to @wpank for help uncovering this issue.
2019-01-07 22:38:21 +00:00
cmd: ["yarn", "run", "--silent", "lint"],
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
deps: [],
},
{
id: "flow",
Tests use yarn not npm (#1038) Currently, our underlying test script uses npm rather than yarn to execute the tests. This is awkward, because we use yarn everywhere else in lieu of npm. It turns out that some setups have node available without npm, and in such environments our tests fail with a cryptic ENOENT error. This changes the tests to use yarn instead. Test plan: `yarn test --full` passes. Thanks to @wpank for help uncovering this issue.
2019-01-07 22:38:21 +00:00
cmd: ["yarn", "run", "--silent", "flow", "--quiet", "--max-warnings=0"],
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
deps: [],
},
{
package.json: reorganize test commands (#571) Summary: Running `yarn test` (equiv. `npm test` or `npm run test`) now runs all checks. It takes the place of the former `yarn travis`. This is more in line with the expectation of a top-level `test` command: if it passes, your code is good. The `unit` command now runs Jest once, not in watch mode. It takes the place of the former `ci-test`. To run tests in watch mode, run any of the following: - `yarn unit --watch`, or - `npm run unit -- --watch`, or - `npm unit -- --watch`. This behavior is more consistent with the standard behavior of commands like `make test`. It is also empirically what @wchargin and @decentralion want most of the time. Test Plan: Verify that each of the scripts `test`, `unit`, and `coverage` passes. Verify that each of the aforementioned `--watch` invocations works. Verify that `.travis.yml` has the correct `script:` command. wchargin-branch: reorganize-test-command
2018-07-31 17:53:10 +00:00
id: "unit",
Tests use yarn not npm (#1038) Currently, our underlying test script uses npm rather than yarn to execute the tests. This is awkward, because we use yarn everywhere else in lieu of npm. It turns out that some setups have node available without npm, and in such environments our tests fail with a cryptic ENOENT error. This changes the tests to use yarn instead. Test plan: `yarn test --full` passes. Thanks to @wpank for help uncovering this issue.
2019-01-07 22:38:21 +00:00
cmd: ["yarn", "run", "--silent", "unit", "--ci", "--maxWorkers=4"],
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
deps: [],
},
Add helpful message when missing gnu-coreutils (#1034) As described in #1033: Currently, developers in environments without gnu coreutils (notably: macOS) get an extremely confusing error message when they run `yarn test`. This commit ensures that such users instead get a helpful message with a link to the fix. Follows @wchargin's proposed approach for fixing #1033, so that Mac developers get clear guidance on how to get their development environment working properly. Expected behavior is that `yarn test` passes when GNU coreutils are present, and fails with the following message when they are not: Fixes #1033 ``` FAIL check-gnu-coreutils Exit code: 1 Contents of stdout: /home/dandelion/git/sc/sourcecred Contents of stderr: Error: Your environment does not provide GNU coreutils You're likely developing on macOS. Please see the following link for a fix: https://github.com/sourcecred/sourcecred/issues/698#issuecomment-417202213 ``` Test plan: Verify that on a machine with gnu coreutils present, the command passes and does not print irrelevant output. Verify that on a machine without gnu coreutils available, the command fails, and prints exactly the error message expected, without any extra output related to the test's implementation. Paired-with: @anthrocypher
2019-01-05 20:20:07 +00:00
{
id: "check-gnu-coreutils",
cmd: ["./scripts/check-gnu-coreutils.sh"],
deps: [],
},
Add `sharness` for shell-based testing (#597) Summary: We will shortly want to perform testing of shell scripts; it makes the most sense to do so via the shell. We could roll our own testing framework, but it makes more sense to use an existing one. By choosing Sharness, we’re in good company: `go-ipfs` and `go-multihash` use it as well, and it’s derived from Git’s testing library. I like it a lot. For now, we need a dummy test file; our test runner will fail if there are no tests to run. As soon as we have a real test, we can remove this. This commit was generated by following the “per-project installation” instructions at https://github.com/chriscool/sharness, and by additionally including that repository’s `COPYING` file as `SHARNESS_LICENSE`, with a header prepended. I considered instead adding Sharness as a submodule, which is supported and has clear advantages (e.g., you can update the thing), but opted to avoid the complexity of submodules for now. Test Plan: Create the following tests in the `sharness` directory: ```shell $ cat sharness/good.t #!/bin/sh test_description='demo of passing tests' . ./sharness.sh test_expect_success "look at me go" true test_expect_success EXPENSIVE "this may take a while" 'sleep 2' test_done # vim: ft=sh $ cat sharness/bad.t #!/bin/sh test_description='demo of failing tests' . ./sharness.sh test_expect_success "I don't feel so good" false test_done # vim: ft=sh ``` Note that `yarn sharness` and `yarn test` fail appropriately. Note that `yarn sharness-full` fails appropriately after taking two extra seconds, and `yarn test --full` runs the latter. Each failure message should print the name of the failing test case, not just the suite name, and should indicate that the passing tests passed. Then, remove `sharness/bad.t`, and note that the above commands all pass, with the `--full` variants still taking longer. Finally, remove `sharness/good.t`, and note that the above commands all pass (and all pass quickly). wchargin-branch: add-sharness
2018-08-06 19:56:25 +00:00
{
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
id: "backend",
Add `sharness` for shell-based testing (#597) Summary: We will shortly want to perform testing of shell scripts; it makes the most sense to do so via the shell. We could roll our own testing framework, but it makes more sense to use an existing one. By choosing Sharness, we’re in good company: `go-ipfs` and `go-multihash` use it as well, and it’s derived from Git’s testing library. I like it a lot. For now, we need a dummy test file; our test runner will fail if there are no tests to run. As soon as we have a real test, we can remove this. This commit was generated by following the “per-project installation” instructions at https://github.com/chriscool/sharness, and by additionally including that repository’s `COPYING` file as `SHARNESS_LICENSE`, with a header prepended. I considered instead adding Sharness as a submodule, which is supported and has clear advantages (e.g., you can update the thing), but opted to avoid the complexity of submodules for now. Test Plan: Create the following tests in the `sharness` directory: ```shell $ cat sharness/good.t #!/bin/sh test_description='demo of passing tests' . ./sharness.sh test_expect_success "look at me go" true test_expect_success EXPENSIVE "this may take a while" 'sleep 2' test_done # vim: ft=sh $ cat sharness/bad.t #!/bin/sh test_description='demo of failing tests' . ./sharness.sh test_expect_success "I don't feel so good" false test_done # vim: ft=sh ``` Note that `yarn sharness` and `yarn test` fail appropriately. Note that `yarn sharness-full` fails appropriately after taking two extra seconds, and `yarn test --full` runs the latter. Each failure message should print the name of the failing test case, not just the suite name, and should indicate that the passing tests passed. Then, remove `sharness/bad.t`, and note that the above commands all pass, with the `--full` variants still taking longer. Finally, remove `sharness/good.t`, and note that the above commands all pass (and all pass quickly). wchargin-branch: add-sharness
2018-08-06 19:56:25 +00:00
cmd: [
Tests use yarn not npm (#1038) Currently, our underlying test script uses npm rather than yarn to execute the tests. This is awkward, because we use yarn everywhere else in lieu of npm. It turns out that some setups have node available without npm, and in such environments our tests fail with a cryptic ENOENT error. This changes the tests to use yarn instead. Test plan: `yarn test --full` passes. Thanks to @wpank for help uncovering this issue.
2019-01-07 22:38:21 +00:00
"yarn",
Add `sharness` for shell-based testing (#597) Summary: We will shortly want to perform testing of shell scripts; it makes the most sense to do so via the shell. We could roll our own testing framework, but it makes more sense to use an existing one. By choosing Sharness, we’re in good company: `go-ipfs` and `go-multihash` use it as well, and it’s derived from Git’s testing library. I like it a lot. For now, we need a dummy test file; our test runner will fail if there are no tests to run. As soon as we have a real test, we can remove this. This commit was generated by following the “per-project installation” instructions at https://github.com/chriscool/sharness, and by additionally including that repository’s `COPYING` file as `SHARNESS_LICENSE`, with a header prepended. I considered instead adding Sharness as a submodule, which is supported and has clear advantages (e.g., you can update the thing), but opted to avoid the complexity of submodules for now. Test Plan: Create the following tests in the `sharness` directory: ```shell $ cat sharness/good.t #!/bin/sh test_description='demo of passing tests' . ./sharness.sh test_expect_success "look at me go" true test_expect_success EXPENSIVE "this may take a while" 'sleep 2' test_done # vim: ft=sh $ cat sharness/bad.t #!/bin/sh test_description='demo of failing tests' . ./sharness.sh test_expect_success "I don't feel so good" false test_done # vim: ft=sh ``` Note that `yarn sharness` and `yarn test` fail appropriately. Note that `yarn sharness-full` fails appropriately after taking two extra seconds, and `yarn test --full` runs the latter. Each failure message should print the name of the failing test case, not just the suite name, and should indicate that the passing tests passed. Then, remove `sharness/bad.t`, and note that the above commands all pass, with the `--full` variants still taking longer. Finally, remove `sharness/good.t`, and note that the above commands all pass (and all pass quickly). wchargin-branch: add-sharness
2018-08-06 19:56:25 +00:00
"run",
"--silent",
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
"backend",
"--output-path",
backendOutput,
Add `sharness` for shell-based testing (#597) Summary: We will shortly want to perform testing of shell scripts; it makes the most sense to do so via the shell. We could roll our own testing framework, but it makes more sense to use an existing one. By choosing Sharness, we’re in good company: `go-ipfs` and `go-multihash` use it as well, and it’s derived from Git’s testing library. I like it a lot. For now, we need a dummy test file; our test runner will fail if there are no tests to run. As soon as we have a real test, we can remove this. This commit was generated by following the “per-project installation” instructions at https://github.com/chriscool/sharness, and by additionally including that repository’s `COPYING` file as `SHARNESS_LICENSE`, with a header prepended. I considered instead adding Sharness as a submodule, which is supported and has clear advantages (e.g., you can update the thing), but opted to avoid the complexity of submodules for now. Test Plan: Create the following tests in the `sharness` directory: ```shell $ cat sharness/good.t #!/bin/sh test_description='demo of passing tests' . ./sharness.sh test_expect_success "look at me go" true test_expect_success EXPENSIVE "this may take a while" 'sleep 2' test_done # vim: ft=sh $ cat sharness/bad.t #!/bin/sh test_description='demo of failing tests' . ./sharness.sh test_expect_success "I don't feel so good" false test_done # vim: ft=sh ``` Note that `yarn sharness` and `yarn test` fail appropriately. Note that `yarn sharness-full` fails appropriately after taking two extra seconds, and `yarn test --full` runs the latter. Each failure message should print the name of the failing test case, not just the suite name, and should indicate that the passing tests passed. Then, remove `sharness/bad.t`, and note that the above commands all pass, with the `--full` variants still taking longer. Finally, remove `sharness/good.t`, and note that the above commands all pass (and all pass quickly). wchargin-branch: add-sharness
2018-08-06 19:56:25 +00:00
],
deps: [],
},
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
{
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
id: {BASIC: "sharness", FULL: "sharness-full"}[mode],
cmd: withSourcecredBinEnv([
Tests use yarn not npm (#1038) Currently, our underlying test script uses npm rather than yarn to execute the tests. This is awkward, because we use yarn everywhere else in lieu of npm. It turns out that some setups have node available without npm, and in such environments our tests fail with a cryptic ENOENT error. This changes the tests to use yarn instead. Test plan: `yarn test --full` passes. Thanks to @wpank for help uncovering this issue.
2019-01-07 22:38:21 +00:00
"yarn",
backend: invoke Webpack directly in package script (#782) Summary: This commit removes the `config/backend.js` script and replaces it with a direct invocation of Webpack. This enables us to use command-line arguments to Webpack, like `--output-path`. Test Plan: Note that `rm -rf bin; yarn backend` still works, and that the resulting applications work (`node bin/sourcecred.js load`). Note that `yarn test` and `yarn test --full` still work. wchargin-branch: backend-webpack-direct
2018-09-05 19:28:27 +00:00
"run",
"--silent",
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
{BASIC: "sharness", FULL: "sharness-full"}[mode],
]),
Add helpful message when missing gnu-coreutils (#1034) As described in #1033: Currently, developers in environments without gnu coreutils (notably: macOS) get an extremely confusing error message when they run `yarn test`. This commit ensures that such users instead get a helpful message with a link to the fix. Follows @wchargin's proposed approach for fixing #1033, so that Mac developers get clear guidance on how to get their development environment working properly. Expected behavior is that `yarn test` passes when GNU coreutils are present, and fails with the following message when they are not: Fixes #1033 ``` FAIL check-gnu-coreutils Exit code: 1 Contents of stdout: /home/dandelion/git/sc/sourcecred Contents of stderr: Error: Your environment does not provide GNU coreutils You're likely developing on macOS. Please see the following link for a fix: https://github.com/sourcecred/sourcecred/issues/698#issuecomment-417202213 ``` Test plan: Verify that on a machine with gnu coreutils present, the command passes and does not print irrelevant output. Verify that on a machine without gnu coreutils available, the command fails, and prints exactly the error message expected, without any extra output related to the test's implementation. Paired-with: @anthrocypher
2019-01-05 20:20:07 +00:00
deps: ["backend", "check-gnu-coreutils"],
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
},
Build backend applications in CI (#193) Summary: This could catch failures in build configuration or with Webpack. It’s unlikely to catch any logic errors, because no production code is run. In any case, it’s fast enough; it finishes at about the same time as `ci-test` and `check-pretty`. Test Plan: From the repository root, run `rm -r bin; yarn travis`, and note that the `bin/` directory is regenerated. wchargin-branch: ci-backend
2018-05-03 05:16:48 +00:00
];
const extraTasks = [
Port GitHub data ingestion into v3 (#378) This commit copies the following logic necessary for downloading GitHub data into v3. Minimal changes have been made to accomodate the new path structure. Test plan: - Manually ran plugins/github/fetchGithubRepoTest.sh and verified that it can correctly pass and fail - Added the v3 github repo test to `yarn travis --full` - Ran `yarn travis --full` and it passed Paired with @wchargin
2018-06-12 01:57:37 +00:00
{
Change `src/v3/` to `src/` and remove v3 naming (#474) Test plan: `git grep -i v3` only shows incidental hits in longer strings `yarn travis --full` passes `yarn backend` works `yarn build` works `yarn start` works `node bin/sourcecred.js start` works `node bin/sourcecred.js load sourcecred example-github` works Paired with @wchargin
2018-06-30 23:01:54 +00:00
id: "fetchGithubRepoTest",
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
cmd: withSourcecredBinEnv([
"./src/plugins/github/fetchGithubRepoTest.sh",
"--no-build",
]),
deps: ["backend"],
Port GitHub data ingestion into v3 (#378) This commit copies the following logic necessary for downloading GitHub data into v3. Minimal changes have been made to accomodate the new path structure. Test plan: - Manually ran plugins/github/fetchGithubRepoTest.sh and verified that it can correctly pass and fail - Added the v3 github repo test to `yarn travis --full` - Ran `yarn travis --full` and it passed Paired with @wchargin
2018-06-12 01:57:37 +00:00
},
Add `fetchGithubOrg` for loading organizations (#1117) This commit adds a module, `fetchGithubOrg`, which loads data on GitHub organizations, most notably including the list of repositories in that org. The structure of this commit is heavily influenced by review feedback from @wchargin's [review] of a related PR. Test plan: This logic depends on actually hitting GitHub's API, so the tests are modeled off the related `fetchGithubRepo` module. There is a new shell test, `src/plugins/github/fetchGithubOrgTest.sh`, which verifies that that the org loading logic works via a snapshot. To verify the correctness of this commit, I've performed the following checks: - `yarn test --full` passes - inspection of `src/plugins/github/example/example-organization.json` confirms that the list of repositories matches the repos for the "sourcecred-test-organization" organization - manually breaking the snapshot (by removing a repo from the snapshot) causes `yarn test --full` to fail - running `src/plugins/github/fetchGithubOrgTest.sh -u` restores the snapshot, afterwhich `yarn test --full` passes again. [review]: https://github.com/sourcecred/sourcecred/pull/1089#pullrequestreview-204577637
2019-03-20 02:00:08 +00:00
{
id: "fetchGithubOrgTest",
cmd: withSourcecredBinEnv([
"./src/plugins/github/fetchGithubOrgTest.sh",
"--no-build",
]),
deps: ["backend"],
},
Copy graph-independent V1 Git plugin code to V3 (#401) Summary: Many files are unchanged. Some files have had paths updated, or new build/test targets added. The `types.js` file includes payload type definitions. These are technically independent of the graph abstraction (i.e., nothing from V1 is imported and the code all still works), but it of course implicitly depends on the V1 model. For now, we include the entirety of this file, just so that we have a clean copy operation. Subsequent commits will strip out this extraneous code. Suggest reviewing with the `--find-copies-harder` argument to Git’s diffing functions. Test Plan: Running `yarn travis --full` passes. Running ./src/v3/plugins/git/demoData/synchronizeToGithub.sh --dry-run yields “Everything up-to-date”. wchargin-branch: git-v3-copy
2018-06-20 22:28:37 +00:00
{
Change `src/v3/` to `src/` and remove v3 naming (#474) Test plan: `git grep -i v3` only shows incidental hits in longer strings `yarn travis --full` passes `yarn backend` works `yarn build` works `yarn start` works `node bin/sourcecred.js start` works `node bin/sourcecred.js load sourcecred example-github` works Paired with @wchargin
2018-06-30 23:01:54 +00:00
id: "loadRepositoryTest",
test: invoke `yarn backend` only once (#784) Summary: Lots of tests need the output of `yarn backend`. Before this commit, they tended to create it themselves. This was slow and wasteful, and also could in principle have race conditions (though in practice usually tended not to). This commit updates tests to respect a `SOURCECRED_BIN` environment variable indicating the path to an existing directory of backend applications. Closes #765. Test Plan: Running `yarn test --full` passes. Prepending `echo run >>/tmp/log &&` to the `backend` script in `package.json` and running `yarn test --full` results in a log file containing only one line, indicating that the script really is run only once. wchargin-branch: deduplicate-backend
2018-09-05 19:47:54 +00:00
cmd: withSourcecredBinEnv([
"./src/plugins/git/loadRepositoryTest.sh",
"--no-build",
]),
deps: ["backend"],
Copy graph-independent V1 Git plugin code to V3 (#401) Summary: Many files are unchanged. Some files have had paths updated, or new build/test targets added. The `types.js` file includes payload type definitions. These are technically independent of the graph abstraction (i.e., nothing from V1 is imported and the code all still works), but it of course implicitly depends on the V1 model. For now, we include the entirety of this file, just so that we have a clean copy operation. Subsequent commits will strip out this extraneous code. Suggest reviewing with the `--find-copies-harder` argument to Git’s diffing functions. Test Plan: Running `yarn travis --full` passes. Running ./src/v3/plugins/git/demoData/synchronizeToGithub.sh --dry-run yields “Everything up-to-date”. wchargin-branch: git-v3-copy
2018-06-20 22:28:37 +00:00
},
Implement a custom CI script (#189) Summary: This CI script accomplishes two tasks: 1. It speeds up our build by parallelizing where possible. 2. It opens the possibility for running Travis cron jobs. Currently, this script by default does the same amount of work as our current CI script. However, I’d like to move `yarn backend` into the list of basic actions: a backend build failure should fail CI. Note: this script is written to be executable directly by Node, so we can’t use Flow types with the standard syntax. Instead, we use the comment syntax: https://flow.org/en/docs/types/comments/ Test Plan: The following should pass with useful output: - `npm run travis` - `GITHUB_TOKEN="your_github_token" npm run travis -- --full` The following should fail with useful output: - `npm run travis -- --full` (fail) To test different failure modes, it can be helpful to add ```js {id: "doomed", cmd: ["false"], deps: []}, {id: "orphan", cmd: ["whoami"], deps: ["who", "are", "you"]}, ``` to the list of `basicTasks` in `travis.js`. To test performance: ```shell $ time node ./config/travis.js >/dev/null 2>/dev/null real 0m8.306s user 0m20.336s sys 0m1.364s $ time bash -c \ > 'npm run check-pretty && npm run lint && npm run flow && CI=1 npm run test' \ > >/dev/null 2>/dev/null real 0m12.427s user 0m13.752s sys 0m0.804s ``` A 50% savings is not bad at all—and the raw time saved should only improve from here on, as the individual steps start taking more time. wchargin-branch: custom-ci
2018-05-02 23:10:03 +00:00
];
switch (mode) {
case "BASIC":
return basicTasks;
case "FULL":
return [].concat(basicTasks, extraTasks);
default:
/*:: (mode: empty); */ throw new Error(mode);
}
}