| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
`maud`, which was the main reason for nightlies, relies on proc macros. Those are stable in the 2021 edition, and maud 0.23+ uses them in a stable-friendly way.
|
| |
|
|
| |
Now that it's done in two (well, three, if you count the README) places, it's best if its done consistently.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
