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

72 lines
1.5 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
Change `execDependencyGraph` export format (#216) Summary: To be honest, I have no idea what exactly this does or why it’s necessary, but if we don’t do this then it is not possible to `import` the exported member from a Webpack-bundled script. I’ve seen this pattern before; one day I’ll actually figure out what it does. :-) Test Plan: Note that `yarn travis` (success) and `yarn travis --full` (failure; no GitHub token) both have the expected behaviors. wchargin-branch: execdependencygraph-export
2018-05-07 17:30:56 +00:00
const execDependencyGraph = require("../src/tools/execDependencyGraph").default;
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() {
const mode =
process.env["TRAVIS_EVENT_TYPE"] === "cron" ||
process.argv.includes("--full")
? "FULL"
: "BASIC";
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
execDependencyGraph(makeTasks(mode)).then(({success}) => {
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
});
}
function makeTasks(mode /*: "BASIC" | "FULL" */) {
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: [],
},
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",
Run npm scripts with `--silent` in CI (#191) Summary: This prevents the boilerplate output of the form ``` > sourcecred-explorer@0.1.0 check-pretty /home/wchargin/git/sourcecred > prettier --list-different '**/*.js' ``` (superfluous linebreaks included). In the case that a script fails, it also omits the giant “this is most likely not a problem with npm” block. The downside to this is that it suppresses any errors in npm-run-script itself. For instance, `npm run wat` produces “missing script: wat”, while `npm run --silent wat` just silently exits with 1. This does not silence the actual scripts themselves, so things like lint errors or test failures will still appear. Test Plan: Run `yarn travis` before and after this commit, and note that the resulting build log is prettier after. wchargin-branch: ci-silent
2018-05-03 02:10:37 +00:00
cmd: ["npm", "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",
Run npm scripts with `--silent` in CI (#191) Summary: This prevents the boilerplate output of the form ``` > sourcecred-explorer@0.1.0 check-pretty /home/wchargin/git/sourcecred > prettier --list-different '**/*.js' ``` (superfluous linebreaks included). In the case that a script fails, it also omits the giant “this is most likely not a problem with npm” block. The downside to this is that it suppresses any errors in npm-run-script itself. For instance, `npm run wat` produces “missing script: wat”, while `npm run --silent wat` just silently exits with 1. This does not silence the actual scripts themselves, so things like lint errors or test failures will still appear. Test Plan: Run `yarn travis` before and after this commit, and note that the resulting build log is prettier after. wchargin-branch: ci-silent
2018-05-03 02:10:37 +00:00
cmd: ["npm", "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",
Run npm scripts with `--silent` in CI (#191) Summary: This prevents the boilerplate output of the form ``` > sourcecred-explorer@0.1.0 check-pretty /home/wchargin/git/sourcecred > prettier --list-different '**/*.js' ``` (superfluous linebreaks included). In the case that a script fails, it also omits the giant “this is most likely not a problem with npm” block. The downside to this is that it suppresses any errors in npm-run-script itself. For instance, `npm run wat` produces “missing script: wat”, while `npm run --silent wat` just silently exits with 1. This does not silence the actual scripts themselves, so things like lint errors or test failures will still appear. Test Plan: Run `yarn travis` before and after this commit, and note that the resulting build log is prettier after. wchargin-branch: ci-silent
2018-05-03 02:10:37 +00:00
cmd: ["npm", "run", "--silent", "flow"],
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: "ci-test",
Run npm scripts with `--silent` in CI (#191) Summary: This prevents the boilerplate output of the form ``` > sourcecred-explorer@0.1.0 check-pretty /home/wchargin/git/sourcecred > prettier --list-different '**/*.js' ``` (superfluous linebreaks included). In the case that a script fails, it also omits the giant “this is most likely not a problem with npm” block. The downside to this is that it suppresses any errors in npm-run-script itself. For instance, `npm run wat` produces “missing script: wat”, while `npm run --silent wat` just silently exits with 1. This does not silence the actual scripts themselves, so things like lint errors or test failures will still appear. Test Plan: Run `yarn travis` before and after this commit, and note that the resulting build log is prettier after. wchargin-branch: ci-silent
2018-05-03 02:10:37 +00:00
cmd: ["npm", "run", "--silent", "ci-test"],
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: "backend",
Run npm scripts with `--silent` in CI (#191) Summary: This prevents the boilerplate output of the form ``` > sourcecred-explorer@0.1.0 check-pretty /home/wchargin/git/sourcecred > prettier --list-different '**/*.js' ``` (superfluous linebreaks included). In the case that a script fails, it also omits the giant “this is most likely not a problem with npm” block. The downside to this is that it suppresses any errors in npm-run-script itself. For instance, `npm run wat` produces “missing script: wat”, while `npm run --silent wat` just silently exits with 1. This does not silence the actual scripts themselves, so things like lint errors or test failures will still appear. Test Plan: Run `yarn travis` before and after this commit, and note that the resulting build log is prettier after. wchargin-branch: ci-silent
2018-05-03 02:10:37 +00:00
cmd: ["npm", "run", "--silent", "backend"],
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: [],
},
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 = [
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: "fetchGithubRepoTest",
cmd: ["./src/plugins/github/fetchGithubRepoTest.sh", "--no-build"],
deps: ["backend"],
},
{
id: "loadRepositoryTest",
cmd: ["./src/plugins/git/loadRepositoryTest.sh", "--no-build"],
deps: ["backend"],
},
];
switch (mode) {
case "BASIC":
return basicTasks;
case "FULL":
return [].concat(basicTasks, extraTasks);
default:
/*:: (mode: empty); */ throw new Error(mode);
}
}