The README explains how to set the SOURCECRED_GITHUB_TOKEN, but later in
the Docker section. People who aren't using Docker will follow the
initial installation instructions. This commit adds the instructions to
set that up when users first install and set up SourceCred.
The eslint no-constant-condition rule disallows while(true) loops,
since the true is a constant condition. However, I find the allowed
alternative (`for (;;)`) less readable, so I am adding the sub-rule that
allows constant conditions for loops.
Test plan: A followon commit uses a while(true) loop, and, assuming this
patch is applied, it does not result in a lint error.
Co-authored-by: Robin van Boven <497556+Beanow@users.noreply.github.com>
Note, unless you used the SourceCred Docker image's bundled
npm or yarn to install your own package.json dependencies,
you were not vulnerable. Otherwise the same risk applies as
[in this NPM blog][1].
You can patch the vulnerability by using the latest Docker image
using `docker pull sourcecred/sourcecred` as soon as this commit
is included in the latest release.
## Commit details
In a [recent security issue][1] found in NPM and Yarn, handling
binary file installation has changed. Quoting from there:
> The bin script linking libraries in use in npm v6.13.4 were
> updated such that, when installing binary entries of top-level
> globally installed packages, they will only overwrite existing
> binary files if they are currently installed on behalf of the
> same package being installed. For example, npm install –global
> foo could overwrite /usr/local/bin/foo if and only if
> /usr/local/bin/foo is currently a link to a previously installed
> version of foo.
In our case, we specifically want this behavior in our Dockerfile.
The node:12 base image comes with an NPM and Yarn version installed.
We're using npm i -g yarn@<version> to upgrade the yarn installation
to a predictable minimum, should we have an older version from the
base image. But since they're from different installation sources,
it causes an error as it would overwrite the yarn binary that wasn't
previously owned by npm install.
Our own package.json or yarn.lock did not appear to have any risk
of exploitation. However since we bundle our image with npm and yarn,
people using our image could in theory use it to install their own
packages. Meaning we should include the fixed npm and yarn versions
to protect users in such a scenario.
[1]: https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli
* chore(package): yarn upgrade
Updates all packages within version range.
* Bugfix update stacktrace matching code
The stacktrace has changed, most likely due to
a babel plugin updating. It now seems based on
the name of the `handlingErrors` argument
instead of the variable name storing the
anonymous function.
* Bugfix update react-router patch version
By updating the react packages, warnings were
logged about unsafe componentWillMount usage.
These warnings tripped a unit test.
react-router was the cause of these, so this
update avoids getting the warnings.
- Have "topic" reflect actual method name.
- Add missing 403 and 429 test for likes.
- Preemptively change method used for headers,
as .post will be obsolete after refactor.
This extends the MockFetcher in the tests
to provide new semantics update mode 2 relies on.
They're based on the below changes to the Fetcher:
- add categoryId and bumpedMs to Topic data #1454
- make topicWithPosts fetch all posts #1455
- add categoryDefinitionTopicIds to fetcher #1456
- implement topicsBumpedSince in fetcher #1457
Particularly because the addition of two new concepts
(categories and category definition topics), the API of
the MockFetcher got rather convoluted. This refactor
makes it behave a lot more like you'd be familiar with
within Discourse.
Such as, creating a topic creates it's opening post
as a side effect. Instead of a post with an unknown
topic ID creating a topic as a side effect.
And creating a category creates it's category
definition topic as a side effect.
Also, we're being a lot more explicit, using objects
instead of positional arguments.
This is to prepare for mode 2 being tested side-by-side.
The normalizeMode1Topics function enforces bumpedMs is not
updated for mode 1 tests.
Additionally describe "update semantics" is redundant,
as the mirror has no other function than update.
Previously an inline check was used for this.
It only accepted the personal access token format.
This adds installation tokens as requested in #1461.
With more complex logic, we'd benefit from tests.
Therefore it's a separate function with a test suite.
Idempotent insert/replace of a Topic, including all it's Posts.
Note: this will insert new posts, update existing posts and delete
old posts. As these are separate queries, we use a transaction here.
This is to be used in the new update logic, which also fetches
all posts of a topic when the topic is loaded. In particular
this allows post editing, which is important for wiki's such as
those used for the initiative system.
bumpedMsForTopic
For the given topic ID, retrieves the bumpedMs value.
Returns null, when the topic wasn't found.
Used by the new update code as a fallback value when making API
calls that don't contain the bumpedMs field.
topicsInCategories
Finds the TopicIds of topics that have one of the categoryIds as
it's category.
Useful to find out which topics a set of categories contains.
For example to implement the `recheckTopicsInCategories` mirror
option, or to locate topics for the initiative plugin.
This is an alternative to solve #1440, taking my
review comments from #1443, to narrow the error handling
to just 404s from the server and crash on other errors.
@wchargin identified issues with the way we setup and reset the warning
mocks in discourse/mirror.test.js. During testing, we found issues where
an unexpected warning might not cause test failures, or an unexpected
warning could break subsequent tests.
This commit fixes both issues.
Test plan: Besides the fact that `yarn test` passes, we've found that
adding a single unexpected console.warn to a test will cause that test
(and only that test) to fail.
Paired with @wchargin
This fixes the non-recoverable error in #1440; namely SourceCred
crashing when the Discourse server returns 404 for a user's actions. I'm
not sure why this happens (maybe DB is in an inconsistent state?) but
missing the likes for a particular user is less frustrating than not
being able to load cred at all.
I've also added a unit test which verifies this behavior; I've confirmed
that before applying the fix, test test fails.
Test plan: `yarn test`
Summary:
We’ve hitherto only run `yarn test` on each commit, to reduce latency.
This commit introduces an advisory (non-blocking) `yarn test --full`
run. Our GitHub branch protection rule is configured to only require
that the `test` task pass before blessing the PR, which is why the
Docker tag preview job doesn’t also block merging. In the case that a
commit is approved quickly and needs to be merged immediately, this
doesn’t get in your way. In all other cases, this can help prevent
breakages.
Test Plan:
Watch the CI run for this commit. Note that all jobs are running, but
only the `test` job is marked as required; see [screenshot][1].
[1]: https://user-images.githubusercontent.com/4317806/68623255-edce3900-0488-11ea-948f-a0cab5174a35.png
wchargin-branch: ci-advisory-full
Summary:
Generated with `./scripts/update_snapshots.sh`. This fixes failures
introduced in #1431.
Test Plan:
Running `yarn test --full` now passes. Inspecting the diff shows that
this only includes a compat version number change, which is appropriate.
wchargin-branch: fix-1431-failures
Summary:
Most changes due to <https://github.com/prettier/prettier/pull/6694>.
Generated with `yarn add prettier@1.19.1 && yarn prettify`.
Test Plan:
Running `yarn test` suffices.
wchargin-branch: prettier-v1.19.1
This removes all usage of and reference to the admin API key and username. Instead relying on anonymous access of the Discourse API.
This enables anyone to deploy an instance with discourse support, and is much safer, since the admin API key isn't used for this purpose anymore. Once merged I would encourage revoking any admin API keys used in the past.
The only notable remaining reference of the discourse username is in the project file.
Which goes from 0.3.0 to 0.3.1 in a backwards-compatible way here, simply ignoring the username if present. For #1426 I'm expecting a 0.4.0 version, so this is to prevent having to change project files twice.
Test plan: updated the snapshots to their latest anonymous versions. Ran yarn test and anonymous discourse loading from CLI numerous times.
Summary:
The Flow team fixed a lot of bugs related to object spreading recently.
Some of these enable us to simplify our code (`generateGraphqlFlowTypes`
and `mirror`). Some find new genuine errors. Others require suppressions
in place of a larger change.
Test Plan:
Running `yarn flow` now passes.
wchargin-branch: upgrade-flow-v0.111.0
This commit upgrades the legacy explorer to now properly include types
from all loaded plugins, rather than just the GitHub plugin. This makes
the legacy UI much more usable for inspecting SourceCred's own
(multi-plugin) cred.
Test plan: Manual inspection of the frontend. `yarn test` passes.
Part of https://discourse.sourcecred.io/t/fixup-legacy-explorer/316
By keeping the TimelineCred in state instead of the Graph, we can access
the plugin information (and potentially other config) from TimelineCred.
Note that the legacy app does still use old-style cred calculation (no
time weighting).
Test plan: `yarn test`. It's just a refactor.
Part of https://discourse.sourcecred.io/t/fixup-legacy-explorer/316
As suggested in #1420, heretofore the Discourse plugin wasn't actually
picking up mentions. The issue is that the (thoroughly tested) mention
detection logic assumed that mention urls took the form
`$SERVERURL/u/$USERNAME`, but actually they are encoded as a relative link,
as in `/u/$USERNAME`. As such, the logic was internally consistent but
never detected any actual mentions!
It's a good case study in the need for integration tests and not just
unit tests. I've updaded the code so we do have a proper integration
test: references.test.js validates that a topic reference, post
reference, and user mention are all properly detected in the real output
from a Discoures topic.
Test plan: `yarn test` passes; inspect updated snapshots and tests.
Fixes#1420.
I want to have the reference tests depend on real snapshotted data.
Therefore, I'm factoring out the utilities for interacting with the
snapshot data out of fetch.test.js and into snapshotTestUtil.js
Test plan: `yarn test` still passes.
burrrata
Dandelion Mané
Robin van Boven
greenkeeper[bot]
William Chargin
