2023-04-14 21:18:58 +02:00
|
|
|
[workspace]
|
2024-06-03 12:04:40 +02:00
|
|
|
members = ["crates/*"]
|
2023-04-14 21:18:58 +02:00
|
|
|
|
2024-01-26 18:59:06 +01:00
|
|
|
resolver = "2"
|
2024-04-11 18:06:37 +02:00
|
|
|
exclude = ["ui/backend"]
|
2024-01-26 18:59:06 +01:00
|
|
|
|
2023-04-14 21:18:58 +02:00
|
|
|
[workspace.package]
|
2024-06-10 15:42:32 +02:00
|
|
|
version = "18.3.0"
|
2021-04-20 22:53:07 +02:00
|
|
|
authors = ["Ellie Huxtable <ellie@elliehuxtable.com>"]
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
rust-version = "1.77"
|
2020-10-05 02:06:41 +02:00
|
|
|
license = "MIT"
|
2021-04-21 22:32:21 +02:00
|
|
|
homepage = "https://atuin.sh"
|
2023-07-31 00:08:00 +02:00
|
|
|
repository = "https://github.com/atuinsh/atuin"
|
2021-04-26 15:25:57 +02:00
|
|
|
readme = "README.md"
|
|
|
|
|
|
2023-04-14 21:18:58 +02:00
|
|
|
[workspace.dependencies]
|
|
|
|
|
async-trait = "0.1.58"
|
2024-05-14 05:07:20 +02:00
|
|
|
base64 = "0.22"
|
2021-02-14 19:40:51 +01:00
|
|
|
log = "0.4"
|
2024-05-25 14:03:55 +02:00
|
|
|
time = { version = "0.3.36", features = [
|
2024-04-11 17:59:01 +02:00
|
|
|
"serde-human-readable",
|
|
|
|
|
"macros",
|
|
|
|
|
"local-offset",
|
2023-10-25 20:06:59 +02:00
|
|
|
] }
|
2024-06-13 15:33:23 +02:00
|
|
|
clap = { version = "4.5.7", features = ["derive"] }
|
2023-04-14 21:18:58 +02:00
|
|
|
config = { version = "0.13", default-features = false, features = ["toml"] }
|
2023-12-16 20:20:40 +01:00
|
|
|
directories = "5.0.1"
|
2023-04-14 21:18:58 +02:00
|
|
|
eyre = "0.6"
|
|
|
|
|
fs-err = "2.9"
|
2023-09-11 10:26:05 +02:00
|
|
|
interim = { version = "0.1.0", features = ["time"] }
|
2023-12-16 20:20:40 +01:00
|
|
|
itertools = "0.12.0"
|
2023-04-14 21:18:58 +02:00
|
|
|
rand = { version = "0.8.5", features = ["std"] }
|
2023-10-18 00:39:47 +02:00
|
|
|
semver = "1.0.20"
|
2024-05-21 04:49:00 +02:00
|
|
|
serde = { version = "1.0.202", features = ["derive"] }
|
2024-05-06 09:09:24 +02:00
|
|
|
serde_json = "1.0.116"
|
2021-04-20 18:07:11 +02:00
|
|
|
tokio = { version = "1", features = ["full"] }
|
2024-06-24 08:38:48 +02:00
|
|
|
uuid = { version = "1.9", features = ["v4", "v7", "serde"] }
|
2024-03-11 16:28:46 +01:00
|
|
|
whoami = "1.5.1"
|
2024-04-26 13:18:53 +02:00
|
|
|
typed-builder = "0.18.2"
|
2023-07-14 21:44:08 +02:00
|
|
|
pretty_assertions = "1.3.0"
|
feat: rework record sync for improved reliability (#1478)
* feat: rework record sync for improved reliability
So, to tell a story
1. We introduced the record sync, intended to be the new algorithm to
sync history.
2. On top of this, I added the KV store. This was intended as a simple
test of the record sync, and to see if people wanted that sort of
functionality
3. History remained syncing via the old means, as while it had issues it
worked more-or-less OK. And we are aware of its flaws
4. If KV syncing worked ok, history would be moved across
KV syncing ran ok for 6mo or so, so I started to move across history.
For several weeks, I ran a local fork of Atuin + the server that synced
via records instead.
The record store maintained ordering via a linked list, which was a
mistake. It performed well in testing, but was really difficult to debug
and reason about. So when a few small sync issues occured, they took an
extremely long time to debug.
This PR is huge, which I regret. It involves replacing the "parent"
relationship that records once had (pointing to the previous record)
with a simple index (generally referred to as idx). This also means we
had to change the recordindex, which referenced "tails". Tails were the
last item in the chain.
Now that we use an "array" vs linked list, that logic was also replaced.
And is much simpler :D
Same for the queries that act on this data.
----
This isn't final - we still need to add
1. Proper server/client error handling, which has been lacking for a
while
2. The actual history implementation on top
This exists in a branch, just without deletions. Won't be much to
add that, I just don't want to make this any larger than it already
is
The _only_ caveat here is that we basically lose data synced via the old
record store. This is the KV data from before.
It hasn't been deleted or anything, just no longer hooked up. So it's
totally possible to write a migration script. I just need to do that.
* update .gitignore
* use correct endpoint
* fix for stores with length of 1
* use create/delete enum for history store
* lint, remove unneeded host_id
* remove prints
* add command to import old history
* add enable/disable switch for record sync
* add record sync to auto sync
* satisfy the almighty clippy
* remove file that I did not mean to commit
* feedback
2024-01-05 18:57:49 +01:00
|
|
|
thiserror = "1.0"
|
2024-04-29 09:34:00 +02:00
|
|
|
rustix = { version = "0.38.34", features = ["process", "fs"] }
|
2024-05-08 13:09:04 +02:00
|
|
|
tower = "0.4"
|
|
|
|
|
tracing = "0.1"
|
|
|
|
|
|
|
|
|
|
[workspace.dependencies.tracing-subscriber]
|
|
|
|
|
version = "0.3"
|
|
|
|
|
features = ["ansi", "fmt", "registry", "env-filter"]
|
2023-03-31 23:57:37 +02:00
|
|
|
|
2023-04-14 21:18:58 +02:00
|
|
|
[workspace.dependencies.reqwest]
|
|
|
|
|
version = "0.11"
|
2023-04-16 13:25:48 +02:00
|
|
|
features = ["json", "rustls-tls-native-roots"]
|
2022-04-21 19:07:33 +02:00
|
|
|
default-features = false
|
2023-04-14 21:18:58 +02:00
|
|
|
|
|
|
|
|
[workspace.dependencies.sqlx]
|
2024-05-31 10:44:55 +02:00
|
|
|
version = "0.7"
|
2023-10-25 20:06:59 +02:00
|
|
|
features = ["runtime-tokio-rustls", "time", "postgres", "uuid"]
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
|
|
|
|
|
# Config for 'cargo dist'
|
|
|
|
|
[workspace.metadata.dist]
|
2024-06-18 10:18:04 +02:00
|
|
|
# Path that installers should place binaries in
|
2024-06-05 15:56:10 +02:00
|
|
|
install-path = "~/.atuin/bin"
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
# The preferred cargo-dist version to use in CI (Cargo.toml SemVer syntax)
|
2024-06-18 10:18:04 +02:00
|
|
|
cargo-dist-version = "0.16.0"
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
# CI backends to support
|
|
|
|
|
ci = "github"
|
|
|
|
|
# The installers to generate for each app
|
|
|
|
|
installers = ["shell"]
|
|
|
|
|
# Target platforms to build apps for (Rust target-triple syntax)
|
2024-06-18 10:18:04 +02:00
|
|
|
targets = ["aarch64-apple-darwin", "aarch64-unknown-linux-gnu", "aarch64-unknown-linux-musl", "x86_64-apple-darwin", "x86_64-unknown-linux-gnu", "x86_64-unknown-linux-musl"]
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
# Publish jobs to run in CI
|
2024-06-05 15:56:10 +02:00
|
|
|
pr-run-mode = "plan"
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
# Whether to install an updater program
|
|
|
|
|
install-updater = true
|
|
|
|
|
# The archive format to use for non-windows builds (defaults .tar.xz)
|
|
|
|
|
unix-archive = ".tar.gz"
|
2024-06-18 10:18:04 +02:00
|
|
|
# Whether to enable GitHub Attestations
|
|
|
|
|
github-attestations = true
|
chore: switch to cargo dist for releases (#2085)
* chore: switch to cargo dist for releases
From https://axo.dev
cargo-dist handles building releases far better than we can, and do so
for several large projects now.
We will need to change our install script to use the cargo-dist
installer.
Historically, we have used the system package manager wherever possible.
Once switched to the new installer, this will no longer be the case. If
the user wishes to use their package manager, and Atuin is maintained
there, then they can choose to do so.
This way, we can ensure that users are running a known build, can easily
uninstall (just delete the atuin dir), easily update, etc. Builds will
use our lockfile, and can have their checksum verified. Later, I'd like
to introduce build signing.
As Axo are focused on release engineering, they will likely have
resolved many more issues than we have - libc versions, etc.
I'm not particularly happy with our response of "just use your package
manager", as many users seem to have difficulty there. It's unclear what
our installer has done, as this behaviour varies massively across
systems. It's also unclear how some package maintainers may have patched
things
I'm hoping that some better release tooling will lead to more confidence
in the process, and therefore more frequent releases.
Uninstall clarity: #111, #372, #640, #1485, #1546, #2049, #1529
* config
* add protobuf
* test build
* use native arm mac
* lol
* add toolchain
* use 1.78, 2vcpu
* nix flake update
* 1.77
2024-06-05 14:25:01 +02:00
|
|
|
|
|
|
|
|
# The profile that 'cargo dist' will build with
|
|
|
|
|
[profile.dist]
|
|
|
|
|
inherits = "release"
|
|
|
|
|
lto = "thin"
|
|
|
|
|
|
|
|
|
|
[workspace.metadata.dist.github-custom-runners]
|
|
|
|
|
aarch64-apple-darwin = "macos-14"
|
|
|
|
|
aarch64-unknown-linux-gnu = "buildjet-2vcpu-ubuntu-2204-arm"
|
|
|
|
|
aarch64-unknown-linux-musl = "buildjet-2vcpu-ubuntu-2204-arm"
|
