| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* init daemon crate
* wip
* minimal functioning daemon, needs cleanup for sure
* better errors
* add signal cleanup
* logging
* things
* add sync worker
* move daemon crate
* 30s -> 5mins
* make clippy happy
* fix stuff maybe?
* fmt
* trim packages
* rate limit fix
* more protoc huh
* this makes no sense, why linux why
* can it install literally just curl
* windows in ci is slow, and all the newer things will not work there. disable the daemon feature and it will build
* add daemon feature
* maybe this
* ok wut where is protoc
* try setting protoc
* hm
* try copying protoc
* remove optional
* add cross config
* idk nix
* does nix want this?
* some random pkg I found does this
* uh oh
* hack, be gone!
* update contributing
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It never worked, and broke release building. I don't think we need musl
debs, but if so ensure they don't break install scripts
Resolve #1500
|
| |
|
|
|
| |
v2.0.0 of cargo deb added the revision number. I'd rather not change the
output name of our file, so force cargo-deb to stick to the "old"
behaviour
|
| | |
|
| |
|
|
| |
gen-completions (#872)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Clean up
Trigger with everything but release
Remove trigger
|
| |
|
|
|
|
|
| |
Not entirely sure how to test this workflow.
Why weren't ARM64 builds being made anyways? The workflow literally has cases to handle it!
Fixes https://github.com/ellie/atuin/issues/369
|
| | |
|
| |
|
|
|
|
|
| |
* Add gen-completions subcommand for generating shell completions
* Update documentation about generating shell completions
* Include the shell completions in release tarball
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Release v0.7.0
- Update all the crate versions
- Update the demo gif
- Write a changelog
- Adjust the title of the search screen (has the old name still)
- Adjust the colours of the quick-jump numbers (sadly invisible on some
colour schemes as dark grey :/)
* Update README, default config file, docs
* Link usernames
* Trigger release workflow upon release creation, as well as tags
|
| |
|
|
|
| |
- Fix version
- Only build for two targets
|
|
|
First proper release!
- Update install script
- Correct dependencies
- Update workflow release script
|
