I've wanted to make the Git support optional for a long time. However,
since everyone uses the Git backend (and we want to support it even in
the custom binary at Google), there hasn't been much practical reason
to make Git support optional.
Since we now use jj-lib on the server at Google, it does make sense to
have the server not include Git support. In addition to making the
server binary smaller, it would make it easier for us (jj team at
Googlle) to prove that our server is not affected by some libgit2 or
Gitoxide vulnerability. But to be honest, neither of those problems
have come up, so it's more of an excuse to make the Git support
optional at this point.
It turned out to be much simpler than I expected to make Git support
in the lib crate optional. We have done a pretty good job of keeping
Git-related logic separated there.
If we make Git support optional in the lib crate, it's going to make
it a bit harder to move logic from the CLI crate into the lib crate
(as we have planned to do). Maybe that's good, though, since it helps
remind us to keep Git-related logic separated.
This is an alternative to https://github.com/martinvonz/jj/pull/3732. I
think it's pretty important to show the "latest" alias. I don't know a
way to not show any alias for "prerelease" in the version selector
without deleting all of them.
I'll have to then separately delete the directories for the aliases on
the gh-pages branch, so that the URL does not resolve to outdated pages.
The downsides are: this will break https://martinvonz.github.io/jj/main/... and
(only recently created) https://martinvonz.github.io/jj/nightly/... links. We
won't have an always-on demo of how well aliases work for when and if we adjust
how aliases (including the all-important latest alias) work in the future.
However, expanding on #3732 (comment), mike is now randomly alternating between
"nightly" and "main" being the first alias of prerelease (it never promised that
the set of aliases would be ordered). So, the version selector keeps switching
in which version it shows. Previously, this only affected the prerelease docs,
but now it also affects https://martinvonz.github.io/jj/latest/.
I feel like recommending people install Poetry via a package manager was
a mistake. Poetry only supports its latest version, and while newer
versions are sort-of backward-compatible, they print warnings in
different situations and have different bugs. Installing `pipx` via a
package manager, OTOH, works fine, and its older versions work fine.
Using Poetry 1.8+ allows us to use Poetry's new "non-package" mode,
which would no longer print warnings if the user does `poetry install`
instead of `poetry install --no-root`. It's likely that in newer
versions of Poetry, it will become an error.
This means that <https://martinvonz.github.io/jj/latest/index.html> will
not longer redirect to
<https://martinvonz.github.io/jj/v0.18.0/index.html> (or similar) after
the next release, as requested by @jyn514 on Discord. Instead, it will
be a copy.
Originally, the plan was to use mike's symlink functionality and make
`latest` a symlink. See a comment inline for how that didn't work; we
could do that after changing how GitHub Pages are built.
Before the next `jj` release, and after this PR is merged, you can play
with this by going to <https://martinvonz.github.io/jj/main/> which is
an alias for <https://martinvonz.github.io/jj/prerelease/>.
Because of previous commits in this PR, the latest version will be
marked in the version selector as "latest", so hopefully this won't
confuse users.
Due to the parent commit, the "latest" URL will be considered canonical.
See https://github.com/martinvonz/jj/pull/3723 for a screenshot.
This will make it clearer to the users that the "latest" and "v0.??.?"
are the same even if the former does not redirect to the latter (but has
identical contents).
MkDocs material lists the *first* alias for each version, so I also
added a "nightly" alias for "prerelease". Otherwise, users would see the
"main" alias, and might get confused whether they should use "latest" or
"main" docs if they don't realize it's named after the "main" branch.
(Upon testing, it still shows "main" for now, but it should be possible
to fix this after this PR is merged by reordering the aliases directly
in `versions.json` on the gh-pages branch)
The aarch64-darwin macOS runners are actually quite speedy, often the fastest
builders anyway. With the recent improvements to the Nix CI speed in 3f7b5a75e,
this shouldn't be a bottleneck, and will catch build regressions.
When running the `nix build`, the `buildRustPackage` function -- which builds
the `jj` crates -- calls `cargo build --release` with flags like `HOST_CXX`
set. This is called the `buildPhase`. Then, it runs the `checkPhase`, which
calls `cargo nextest`, in our case. However, it does not set `HOST_CXX`, for
some reason.
The intent of `buildRustPackage` is that the `buildPhase` and `checkPhase`
have their compilation options fully aligned so that they reuse the local cargo
`target/` cache directory, avoiding a full recompilation. However, the lack
of `HOST_CXX` above among others causes a cache miss, and a bunch of cascading
recompilations. The net impact is that we compile all of the codebase once in
`buildPhase`, then again in `checkPhase`, making the Nix CI build 2x slower on
average than the other Linux runners; 2-3 minutes versus 7 minutes, on average.
Instead, re-introduce a 'check' into the Flake directly, which overrides the
`jujustsu` package, but stubs out the `buildPhase`. This means it will only run
`checkPhase`, which is what we want. Then, modify the CI to run `nix flake check`
again, like it used to in the past.
Unfortunately, this doesn't fix the cache miss when running `nix build`
yourself, it recompiles from scratch in both phases still. That needs to be
fixed in the future, but it's tolerable for now.
This reverts most of 71a3045032.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This should nerf some of the impact of the flaky Windows GPG tests right now,
which are currently non-deterministically running into hangs, causing a lot of
PRs to stall out. 15 minutes was chosen as a good trade-off between "pretty far
from our current build times" while also catching obvious bugs and flakes.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
GitHub announced these new Apple Silicon based runners today. Let's take them
for a spin.
Let's also add an entry in the release matrix to build and publish `aarch64-
apple-darwin` binaries, too. This doesn't migrate the old release matrix entry;
it still uses a `macos-11` runner. This means the x86 binaries should work on a
few older macOS versions if users need it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
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
