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

87 lines
1.8 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: [],
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",
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",
Flow: enable `//$ExpectFlowError` (#315) As of this commit, adding the comment `//$ExpectFlowError` in flow-typed code asserts that the next line must cause a flow error. If it does, no error or warning is generated. If it does not, then this produces a flow warning, which is visible to developers running `yarn flow` and additionally causes travis to fail. Test plan: - As committed, `yarn travis` passes. - I added `//$ExpectFlowError` above some line of flow-checked code which does not currently throw an error. Afterwards, `yarn travis` failed (and a helpful message was displayed in console on running `yarn flow`) - I added the following bad code into one of our files: ```javascript //$ExpectFlowError const foo: string = 3; ``` As expected, `yarn flow` and `yarn travis` both passed.
2018-05-29 20:56:36 +00:00
cmd: [
"npm",
"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: [],
},
{
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",
Don’t erase the `bin/` folder in CI (#317) Summary: Previously, our CI script would run `yarn backend`, which has the side-effect of erasing the `bin/` directory. By itself, this is not great, but not awful. However, this frequently triggers a race condition in Prettier, causing the `check-pretty` step of the build to fail. (More details: https://github.com/prettier/prettier/issues/4468.) This patch changes the CI script to build the backend scripts into a temporary directory. Test Plan: Before applying this patch: `yarn backend` and then `yarn travis`. If this consistently causes a Travis failure due to `check-pretty`, then your machine can reproduce the race condition that we‛re trying to eliminate. (Otherwise, you can try creating a bunch more Git history… I’m not really sure what to say. It is a race condition, after all.) Then, apply this patch, and repeat the above steps; note that the error no longer occurs, and that the build output is to a temporary directory. wchargin-branch: ci-preserve-bin
2018-05-29 22:40:42 +00:00
cmd: ["npm", "run", "--silent", "backend", "--", "--dry-run"],
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);
}
}