Summary:
Contributors who open PRs from a fork will need to have their commits
“blessed” by a core team member before the `test-full` CI job will run
successfully. This commit explains that to ward off any confusion.
Test Plan:
This workflow was recently exercised for #1521, successfully.
wchargin-branch: contributing-test-full
* Quicker failure and description when invalid token supplied
Fixes#1156
When users export a GitHub API token that has insufficient privleges
or has been revoked, we have been using a catch all error with retry
to handle it. This change adds a new error type for bad credentials
and does not retry.
Test plan:
There are no unit tests that cover this, however, you can test the
change by supplying a revoked token and attempting to load a GitHub
repo.
* Minor: reunite comment with relevant code block
* Update Changelog: Fail quicker and with information when using invalid GH token (#1161)
* Documentation updates
Added note on Changelog update format, SSH key requirements, and formatted the console (CLI) blocks a little better.
* Minor formatting fixes
* Revert a line wrap commit as it is not appropriate on README.md
* Removed prompt tokens and changed non-visible formatting
We switched from marking beginner-friendly issues "Contributions Welcome"
to "Good First Issue". See sourcecred/pm#15 for discussion.
Test Plan:
The new link works correctly on my local fork.
Summary:
Closes#902. CircleCI continues to work fast and well, on both the
commit and nightly workflows. Travis continues to be slower. It is time.
I have disabled Travis for `sourcecred/sourcecred` via:
<https://travis-ci.org/profile/sourcecred>
This commit removes the vestigial configuration files and code.
Test Plan:
Running `yarn test` still works. Running `yarn test --full` still works,
and properly invokes `sharness-full` and the various extra tests.
Running `git grep -i travis` yields no results.
wchargin-branch: ci-remove-travis
It's more consistent to prepend entries to the [Unreleased] section of
the changelog, so that entries are all in reverse-chronological order.
Since we've appended the first few entries, we reverse them now.
Test plan: Not needed
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
Summary:
Having a guide for contributors makes the experience more pleasant for
everyone. In the best case, contributors read the guide and submit
perfect PRs. In the event that a discrepancy occurs, we can gently point
the contributor to the guide—saving us from having to re-explain common
pitfalls, and signaling to the contributor that this is a matter of
practice and that we are not “out to get them”.
This guide, like all documentation, is intended to evolve over time.
Test Plan:
None.
wchargin-branch: contributing-md
William Chargin
Tyler Mace
Brian Litwin
Dandelion Mané