| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removing this file broke Heroku deployments. The emk/rust buildpack
relies on this file to detect the Rust version, and as this code
_requires_ a nightly, the default stable version fails to deploy.
Unfortunately, this effectively leaves the project pinned to a specific
nightly version until and unless one of a few things happens:
* We remove the test step that verifies formatting,
* Travis adds a non-minimal Rust profile,
* We migrate CI to a service that supports a more complete Rust profile,
or
* Nightly has rustfmt again.
See <https://github.com/emk/heroku-buildpack-rust#specifying-which-version-of-rust-to-use>.
This reverts commit f43bcb502435ccd99e163671204371dd8b62024f.
|
| |\
| |
| | |
Provide a git hook to automate tests.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When enabled, these hooks run the same tests as Travis, every commit.
There's nothing inherently wrong with a failing test run (it's a useful
signal), but the turnaround time for responding to Travis is a lot
longer than the turnaround time for responding to a local test failure.
The tradeoff here is that `git commit`, which is a _very_ common
operation, takes considerably longer when the hooks are enabled, and
runs a higher risk of giving users doorway effect issues.
|
| |\ \
| |/
|/| |
Disregard test strings that can be converted to numbers when testing …
|
| |/
|
|
|
|
|
|
| |
non-numeric strings.
This is a straight oversight in the property. We asserted the proposition "the string contains no NULs implies the string will be rejected," but the test suite found a counterexample: `"0"` contains no NULs and is not rejected.
This is correct behaviour - the string "0" should be converted to the port number 0! So, now the proposition is more complex: "the string contains no NULs and cannot be converted to a number implies the string will be rejected." This closely mirrors the implementation, which isn't fantastic, but I can't see a more succinct and accurate way to frame the property.
|
| |\
| |
| | |
Add missing dependencies for rustfmt Travis pass.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a complicated one. There are a few factors in action here:
* For background, the `maud` library requires nightly. The macro shenanigans it pulls are not supported on stable.
<https://maud.lambda.xyz/getting-started.html>
* Travis installs Rust "cold," with no prior Rust installation, using `rustup`, for each entry in the build matrix. Travis _always_ uses the "minimal" profile.
<https://docs.travis-ci.com/user/languages/rust/#choosing-a-rust-version>
* Since 2020-06-10, the "nightly" release of the Rust language has not included the `rustfmt` component.
<http://rust-lang.github.io/rustup-components-history/>
Note that the information on that page is likely to be different by the time you look at it.
* The Travis test suite requires `rustfmt` to validate commits. See `.travis.yml` for that one.
* Rustup will prefer `rust-toolchain` files over command-line options when selecting a Rust version to install.
Because of this wide range of factors, since the eleventh, it has not been possible to run `rustfmt` via `cargo fmt` on Travis. Tests have been broken since we added `rustfmt` as a mandatory step.
This change causes Travis to use both a known-good nightly (June 10th's), and also to try the build with current nightly. Current nightly is permitted to fail; once this starts passing, we can make that build mandatory and reinstate `rust-toolchain`.
Note that this doesn't affect most developers, as they use `rustup`'s default profile, which always includes `rustfmt`. `rustup` accomplishes this by walking back in time until it finds a nightly build that includes all the components in the profile, but it only does this when installing a fresh toolchain, not when trying to add a component to an installed toolchain.
I would vastly prefer to keep `rust-toolchain`, but it interferes with `rustup`'s installation logic, so it has to go for now.
Score one for never using `nightly`...
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
As of 2020-06-17, rustup nightlies are missing rustfmt, rls, and a few
other components we care about. Pin the rust version, for now, as we
need those components for testing.
Check <https://rust-lang.github.io/rustup-components-history/> to
monitor the contents of nightly releases.
|
| | | |
|
| |/
|
|
| |
That was an experiment that didn't really go anywhere. There are no meaningful "versions" of this software - it runs on a single host, and there are no compatibility promises.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Rust nightly un-broke doctests!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This pulls the top-level framework for HTML out into its own partial.
|
| | |
|
| |
|
|
|
| |
This is a style experiment; the utility of using partials in an app with
one view is limited, to say the least.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This closely matches Procfile entries, making the structure of the project a little easier to follow.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This accomplishes two things:
1. The og cards and page title no longer contain half-baked markup. Instead, they show the markdown equivalent, which is generally pretty friendly. In other words, the page title is "Have you checked `resolv.conf`?" and not "Have you checked <code>resolve.conf</code>?"
2. Phrases can now start with terms other than "Have you checked".
|
| |\ |
|
| |
|
|
| |
This is somewhat overengineered in places, but does the job and exposes broadly the same interfaces as the Python version. Builds with emk/rust.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Jinja2: CVE-2019-10906
In Pallets Jinja before 2.10.1, str.format_map allows a sandbox escape.
* urllib3: CVE-2019-11324
The urllib3 library before 1.24.2 for Python mishandles certain cases where
the desired set of CA certificates is different from the OS store of CA
certificates, which results in SSL connections succeeding in situations where
a verification failure is the correct outcome. This is related to use of the
ssl_context, ca_certs, or ca_certs_dir argument.
* requests: upgraded as it depends on urllib and restricts versions.
* werkzeug: CVE-2019-14806
Pallets Werkzeug before 0.15.3, when used with Docker, has insufficient
debugger PIN randomness because Docker containers share the same machine id.
* gunicorn: No CVE, just good hygiene.
|
| | |
|
| | |
|
| |\
| |
| | |
Update things-to-check.yml
|
| |/
|
| |
RTFM.
|
| |\
| |
| | |
fucking binlogs
|
| | | |
|
| |/
|
| |
system.disk.in_use over device:/dev/xvdf1,host:shared-db was >= 0.85 on average during the last 10m.
|
| | |
|
