The `go` command performs a full load, running the following commands in
sequence:
- load
- graph
- score
We don't include the `site` command, on the premise that the user might
have reasons to not include the site (e.g. they just want to use the
ouptut data for analysis), so we shouldn't add it for them. Also, if
they installed the site in the past, it will still be setup.
However, this does mean that downstream users who DO want a site should
be sure to run `sourcecred site` manually whenever they update
SourceCred versions.
Test plan: In a SC instance, run `sourcecred go` and observe that:
- in the success case, it runs the three commands in sequence
- in the failure case, it prints a message showing which command failed
(you can induce a failure by removing the cache, or unsetting
GitHub/Discord tokens).
This adds a simple sharness snapshot test for the new instance system,
in the model of the old [test_load_example_github.t][old].
I've setup a very simple test instance with the GitHub and Discourse
plugins, and we verify that the output generated by running `load`,
`graph`, and `score` in succession is stable. (Cache is not
persisted.) This is a nice sanity check to verify that nothing ever gets
totally broken; we'll still want to add unit testing for more specific
features and edge cases.
Test plan:
`yarn test --full` passes.
If you `rm -rf sharness/test-instance/output`, then `yarn test --full`
fails.
If you then run `./scripts/update_snapshots.sh`, then the output
directory will be restored; afterwards `yarn test --full` passes again.
To verify that the snapshots are valid, you can test them with the
frontend:
`yarn start --instance sharness/__snapshots__/test-instance`
If you are actually debugging this script, rather than using
`yarn test --full` you'll want to invoke
`(cd sharness; ./load_test_instance.t -l -v)`
[old]: https://github.com/sourcecred/sourcecred/blob/v0.6.0/sharness/test_load_example_github.t
