Summary: It needs new credentials to act as a robot account on my behalf, rather
than the 'github-actions' user, as that one can't be approved for security/legal
reasons from Google.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I72e303b5625a6417d3444fc65cb79a779a5d9d53
This is quite minor, but it took me a few minutes to figure out
the correct command.
It might be slightly better to print this text inside the build
logs, where people will be looking for certain if the CI fails,
but I didn't immediately find a good way to do so without
complicating the config too much.
The dependabot refused to update some dependencies anyway. Maybe it
conservatively checks if all intra dependencies meet a certain version?
```
updater | 2023/12/15 15:56:45 INFO <job_762807265> No update possible for cargo_metadata 0.17.0
updater | 2023/12/15 15:56:54 INFO <job_762807265> No update possible for crossterm 0.26.1
updater | 2023/12/15 15:57:04 INFO <job_762807265> No update possible for itertools 0.11.0
updater | 2023/12/15 15:57:16 INFO <job_762807265> No update possible for zstd 0.12.4
updater | 2023/12/15 15:57:16 INFO <job_762807265> No update possible for jj-cli 0.12.0
updater | 2023/12/15 15:57:27 INFO <job_762807265> No update possible for toml_edit 0.19.15
updater | 2023/12/15 15:57:38 INFO <job_762807265> No update possible for prost-build 0.11.9
updater | 2023/12/15 15:57:49 INFO <job_762807265> No update possible for prost 0.11.9
```
backout of commit 58744d9573
I noticed some cargo dependencies aren't caught by the dependabot. For example,
there are gix updates, but the dependabot somehow thinks it's not possible to
update.
```
updater | 2023/12/14 15:57:52 INFO <job_762380319> Checking if gix 0.55.2 needs updating
proxy | 2023/12/14 15:57:52 [063] GET https://crates.io:443/api/v1/crates/gix
proxy | 2023/12/14 15:57:52 [063] 200 https://crates.io:443/api/v1/crates/gix
updater | 2023/12/14 15:57:53 INFO <job_762380319> Latest version is 0.56.0
...
updater | 2023/12/14 15:58:00 INFO <job_762380319> Requirements to unlock update_not_possible
updater | 2023/12/14 15:58:00 INFO <job_762380319> Requirements update strategy bump_versions
updater | 2023/12/14 15:58:00 INFO <job_762380319> No update possible for gix 0.55.2
```
I don't know what's wrong, but let's try without the grouped updates as it was
working before.
FWIW, this issue looks similar:
https://github.com/dependabot/dependabot-core/issues/7896
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
