Originally, my motivation was to try again to get `mike` to not push empty
commits (which this should do). I'm now reconsidering this, since *not* pushing
empty commits will make the output of the CI job a little harder to read. If
this becomes an issue, I might even add `--allow-empty` to the `mike`
invocations later.
A more important motivation is that even for a 400-byte file, changing it for
every PR blows up the size of the repo eventually.
The cause for the changes to this file was that `gzip` stores a timestamp
inside the `.gz` file.
https://github.com/jimporter/mike/releases/tag/v2.0.0
The main immediate advantage of this is that `mike` will stop pushing empty
commits.
Also, we can consider switching to using symlinks instead of redirects for
mapping the "latest" version to "v0.11.0". This would make
`https://martinvonz.github.io/jj/latest/` have the same content as
`https://martinvonz.github.io/jj/v0.11.0/` (until the next version is out), but
the user would see `latest` in the URL.
For now, I set an option to keep using redirects.
I did a bit of non-exhaustive testing; it seems to work.
Summary: Keeping the flake.lock up to date and 'fresh' is nice for
all the same reasons that apply to things like Cargo, Poetry, etc.
Unfortunately, dependabot doesn't have support for Nix flakes. There is also
no mechanism to add 'out of band' updates through dependabot, at least not yet.
Instead, we use the `update-flake-lock` action from Determinate Systems, which
can paper over it for us.
This updates once a week on Sunday, which is pretty fine, I think.
A theoretical downside of this approach is that we can't group updates together
like dependabot does; but dependabot only groups 'related' updates together,
i.e. updates to Cargo dependencies. If it also detected updates for e.g. Poetry
or Nix, it would make separate PRs for those.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I6f447deffc545da77fb320519abcf437
Summary: Codespell actually matches local files at the root of the repo with the
`./` prefix, so without it the `skip` field won't match. Fix this for `./target`
and `./.jj` directories.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: Ibeafd7e400ff3bca9187d62241296060
Summary: Since 066032b6e6 was merged, the `nix flake check` build no longer
overrides the 'cargo test' profile explicitly, to save disk space. The CI seems
to be in a better spot. This will stem the tide for a while hopefully.
However, with that change in place, the `nix flake check` build was
essentially a redundant, nearly-identical copy of a normal `nix build` with no
differentiating features, except: `RUST_BACKTRACE` is set to 1.
Delete all this code, and remove it from the CI matrix, and instead just export
`RUST_BACKTRACE` on the `checkPhase` of the normal `nix build` instead, which is
functionally equivalent.
Also does some minor, no-functional-change touchups to `flake.nix` while I was
there (whitespace, etc.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I87336b16e2a0b973343ecbde8ffd7b8f
Perhaps this will stop Github from showing jj-docs-bot as a very active
contributor in https://github.com/martinvonz/jj/pulse. This would
probably fair, even though jj-docs-bot tries its best to be a good and
helpful bot.
Regardless, this seems to be the standard on Github which has
`dependabot[bot]` and `github-actions[bot]`.
One action publishes the 'prerelease' version on every push
to `main`.
The other publishes a 'latest' version on every releasse.
I tested both of them, but not with branch protection rules.
I initially was thinking of using `mdbook`, which looks a little better, but I
think versioning the docs is important, and the features I want are pretty much
only supported by the Mkdocs' "Material" theme.
Mkdocs is written in Python. The prerequesites for building docs on your
machine should be to install Python and Poetry, everything else should be
installed automatically by Poetry. See the edits to `contributing.md` for more details.
We run a separate build on CI with the MSRV so we notice if we
accidentally break the MSRV. However, as we talked about on Discord,
the opposite is very unlikely - that we accidentally break the build
with the stable release without breaking the MSRV build. Also, we
explicitly run Clippy with the stable release, and formatting with the
nightly release. So, let's just do the regular build and tests with
the MSRV.
Summary: Here's a fun fact — macos-latest doesn't actually refer to the latest
macOS version used in your GHA runner! It apparently means, tautologically,
"latest macos version that we have chosen as the default." OK?
But why bother? Because word on the street is that the new macos-13 builders
from GitHub are on new hardware, and much faster than previous ones. Let's test
that rumor.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: Ifdbab62e085adbda41a7edb9fc7038f0
Summary: Let's be more aggressive about tracking the latest stable Rust release.
There's little benefit to being conservative so early on, especially when no
users seem to have faced any issue with upgrading, or strictly required an old
Rust version.
Right now, just lagging Rust by 1 major release probably seems fine. We're
targeting 1.71.0 to get ahead of the curve, since 1.72.0 will likely release
sometime before the next `jj` release.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I4e691b6ba63b5b9023a75ae0a6917672
Summary: The Determinate Systems Nix installer is fast and importantly includes
Flake support by default on new installs.
Magic Nix Cache will help ease the build time a little by making sure things
like downloads from crates.io remain cached between builds; in the future if we
ever need to add any custom builds to the Nix expression it will come really in
handy. But in my experience I don't think it should slow down much, and might
speed some things up a whole lot.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I56e1592cbaa6c7a43b5bd57972b98ada
Summary: While I was developing #1846, I found a case where `nix flake check`
succeeded but `nix build` on the jujutsu expression failed, which was confusing
to me. If it had been merged, it would have broke the ability to use Nix to
install things.
Let's try to attack this, and punch a parallel job into the build matrix;
hopefully running the two jobs concurrently can help catch this without
making build time much worse.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: If2520d69492fa6abe499c1cb1d51d6e1
Summary: When building in CI, we just build everything from scratch in the `dev`
profile, so just turn off debuginfo and incremental compilation data. These
aren't reused, but more importantly take up more space and CPU time to generate;
that's more expensive on slower machines and when using The Cloud(TM) to build.
Together, these take a fresh build (`rm -rf target/` ahead of time) from about
40s to 30s on my machine.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: Id6e706634dbaf88f6ccd7f457409ad7c
