summaryrefslogtreecommitdiff
path: root/README.md
Commit message (Collapse)AuthorAge
* Move tool installation into scripts.Owen Jacobson2020-07-31
| | | | Now that it's done in two (well, three, if you count the README) places, it's best if its done consistently.
* Restore rust-toolchain file.Owen Jacobson2020-06-17
| | | | | | | | | | | | | | | | | | | 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.Owen Jacobson2020-06-17
| | | | | | | | | | | 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.
* Move from rust-toolchain to rustup overrides for rust version selection.Owen Jacobson2020-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`...
* Set up travis for continuous testingOwen Jacobson2020-06-16
|
* Add a README and project metadata.Owen Jacobson2020-06-16