| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
Automate periodic Rust Nightly upgrades.
|
| | |
| |
| |
| | |
Now that it's done in two (well, three, if you count the README) places, it's best if its done consistently.
|
| | |
| |
| |
| | |
This allows the project to have a pinned version of Rust, but also ensures we don't fall too far behind on versions so long as someone (cough) reviews the pull requests regularly. This splits the difference between using nightly directly (and having Travis fail sporadically because of missing rustfmt/clippy) and pinning so that Travis works reliably (and having a large version lag).
|
| |\ \
| |/
|/| |
Add an admonishment to check the version you're testing against.
|
| |/
|
|
| |
@wlonkly!)
|
| |\
| |
| | |
Pin nightly again.
|
| |/
|
|
| |
As predicted in 6b271b72d91ece90325b7d1691759d1c2b25707f, nightly-as-of-today is missing tools this project depends on (rustfmt, again).
|
| |\
| |
| | |
Switch from quickcheck to proptest.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The argument is as given in the proptest docs at
<https://altsysrq.github.io/proptest-book/proptest/vs-quickcheck.html>.
I've found that the resulting tests are somewhat clearer, and that the
tools for working with test case generation are more useful.
The other killer feature is recalling test failure examples from run to
run. This change includes at least one bug found while testing the port!
Finally, if <https://github.com/AltSysrq/proptest/issues/179> is to be
believed, proptest is considerably closer to supporting async tests.
|
| |\ \
| |/
|/| |
Revert to nightly.
|
| |/
|
|
| |
As of the 20th, nightly once again has rustfmt, and Travis should build cleanly. I've made no real effort to find a long-term solution - I'm sure sooner or later nightly will lose critical binaries again, breaking the test suite, but I also don't want to pin to nightly-as-of-a-date as I will almost certainly forget to ever upgrade Rust.
|
| |\
| |
| | |
Extracted checks into a tools directory.
|
| |/
|
|
|
|
|
|
|
|
|
| |
Having the checks duplicated between .git-hooks and .travis.yml was a
recipe for them to diverge eventually. This is somewhat tidier, and
creates a clear convention for any future tools-like scripts.
I didn't do the same to install steps, as they're a lot more sensitive to the
specific environment - Travis requires different things from Github, which
requires different things from CircleCI, which requires different things from a
local environment.
|
| |\
| |
| | |
Restore rust-toolchain file.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
