This change improves the `rad clone` command in a few different ways.
The first improvement is to check if the repository already exists before
fetching. If it does exist, then there is no need for the fetch to be performed,
and can move straight to the checkout.
If the repository does not exist, then the fetch is performed, as per usual.
However, it uses a replication factor of 1, so that the fetch finishes as soon
as it has the repository in local storage.
The change also improves the output when failures occur while attempting to
perform the checkout phase. It will print the failure that occurred and provide
a hint message in each case to help debug the failure, or push the caller in the
direction of performing the correct action.
This required some changes in `test/commands.rs` setup. Some tests were using
the `rad-clone.md` to setup a clone, which would have different output if the
repository did not need to be fetched. In those cases, the `rad` method for
performing the clone is used instead.
Reword the help message of `--replicas` and `--max-replicas`, while also
improving the documentation on how the fetch and announce functionality works.
This patch changes separates the business logic of fetching from the process of
fetching itself. It does this through a sans-IO approach, where a `Fetcher`
provides the necessary state to help drive a fetch forward, without performing
any of the IO itself.
What the `Fetcher` cares about is:
- What nodes are going to be attempted to be fetched from
- In what order should they be attempted
- When should the fetching process be considered finished
The `Fetcher` is then used in `radicle-cli` to drive forward the `sync::fetch`
function, allowing it to only care about the IO.
Leverage `schemars` to generate a JSON Schema from our structs for
configurations and those occurring within them.
The output of `rad config schema` can be used by editors to provide a
smoother editing experience for the configuration file. Discovery
attributes (both keys and values) is greatly improved with the schema
helping in the background.
Refer to:
- https://json-schema.org
- https://code.visualstudio.com/docs/languages/json#_json-schemas-and-settings
- https://schemastore.org
- Print link direction.
- Shorten NIDs.
- Use single chars to indicate status, legend is provided via hint.
On nodes with only outgoing connections, link direction won't be very
interesting. But on seed nodes it sometimes *is* of interest in which
direction the connections are going.
Also, I hope that in the future we will enable more and more nodes to
connect directly to each other.
The table header "Dir." is an abbreviation for "Link Direction".
This change is to help separate the fact the namespacing by a `NodeId` is a
Radicle specific concern. The identifier can, in theory, be any kind of path
component, as long it is valid in Git.
The motivation for the change is to help separate the idea of a device's
`NodeId` vs an agent being an author – for future agent repository work.
The motivation of this change is to move away from tying signing to be
specifically for ed25519. The reason being that the protocol will want move
towards two different kinds of signing – the node signing artifacts, and an
author signing artifacts.
This change captures the former, node signing, by introducing a `Device` type
that is the `NodeId` – a PublicKey underneath the hood – and a signing
mechanism. This allows the replacement of the `Signer` trait being used – which
always assumed a `PublicKey`. Instead, the `Device` is constructed with
`NodeId`.
In `radicle-cob`, a signer is expected to implement
`signature::Signer<ExtendedSignature>`, and everywhere in `radicle`,
`radicle-node`, `radicle-cli`, and `radicle-remote-helper` is expected the
signer is expected to implement `signature::Signer<Signature>`.
A `Device` implements both of these but only requires
`signature::Signer<Signature>` to do so – since an `ExtendedSignature` is
essentially `(PublicKey, Signature)`, and the `NodeId` of the `Device` can be
used.
This declares the minimum supported Rust version, independently of the
`rust-toolchain.toml` file, which specifies the Rust version and
toolchain components the crate/workspace should be built with. The
MSRV affects other crates that depend on anything in this workspace,
but the toolchain file does not seem to affect them. This means the
MSRV is useful for those who build or develop dependents.
Signed-off-by: Lars Wirzenius <liw@liw.fi>
To keep expectations similar to the seed command after the changes in
the companion patch:
rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/patch/3be0e68b8948e65431a288f225454bafd93de34a
This introduces rate limits for the `ChannelReader` to limit DDoS attacks and
attempts to upload repositories that are larger than a node is will to permit.
The limiter sets the total number of bytes it is will to accept in a single
exchange, defaulting to 500MB. This means that initial fetches will prevent
large repositories, but is plenty for new packfile data to be sent in subsequent
fetch exchanges.
The limit can be configured within the node's config file, under the limits.
This gives the possibility to see the inventory of another node than self.
This does replicatee the functionality of 'rad node routing --nid', but
feels like a more intuitive command to try.
Update the rust toolchain version to 1.85.
Note that this is not the latest, however, it is the latest available in nixpgs,
so this version is good enough for now.
The help shows that `--emoji` is optional, however it was not.
Instead of making `--emoji` mandatory, I added an emoji picker
for the emojis featured in the web ui.
`--emoji` is now (really) optional, but can be used to react
with other emojis not included in the selector or the web ui.
In the 'clone' command, a 'signer' is instanciated just to get the
public key. In the 'job' command, a 'signer' is instanciated early,
even when the subcommand doesn't use it.
That's unnecessary, and infers the potential use of RAD_PASSPHRASE.
In those cases, avoid instanciating a 'signer'.
Add the remaining `Patch` actions to the CLI interface. These include:
- React to a revision
- Edit a comment
- React to a comment
- Redact a comment
The `react` subcommand is added in a straight-forward manner.
The comment commands are slightly less straight-forward. In order to
keep to one layer of subcommands, these variants are done through the
`rad patch comment` subcommand. They are accessed via options:
`--edit`, `--react`, and `--redact`, respectively. Each of these
options takes the `CommentId` for which the action is affecting. The
`message`, `react` (introduced for `rad patch react`), and `undo`
variables repurposed for this subset of actions.
Indicate that the `rad issue state` operation was successful to the
user by printing a message to the console.
Solves:
rad issue show 71020de8478b15b3f7a619f2f93d3cfb8771cde2
Add the ability to edit an issue comment to the `rad issue` command.
This is achieved by adding an `--edit` option to `rad issue
comment`. Note that if `--reply-to` and `--edit` are both specified,
then this results in an error.
If the user wants to see all `seeded` repositories, we should tell them
to use the `--seeded` option instead of the `--all` option.
Since `--all` also shows repos that aren't being seeded.
There was mishap in updating the parameters of highlight configuration – so many
string types!
This is fixed by adding the correct `name` parameter, reusing the `language`
variable that is being matched on.
When piping the output in for eg. `head -n 1`, the `head` utility
might close down the pipe at some point, yielding a broken pipe error.
We catch that and simply return if that's the case.
If the rad node is spawned by systemd there won't be any logs file
to read and `rad node logs` command will fail with the standard
error message from fs.
Adds the new `migrate` sub-command to migrate the COB database.
Checks for version when opening the COBs database and suggests the
command on out of date version.
Also adds the 2nd migration to the COBs cache, which updates the patch
JSON schema.
The `no quorum found` error can be opaque and lead to a lot of confusion. It is
better to give more information for this error so that it leads to easier
debugging, since it can be quite a common warning/error.
Instead of a single error, there are two cases provided: `NoCandidates` and
`Diverging`, to capture the two different variants of errors that can occur.
`Display` implementations are provided for both to provide more information.
The failure to set a HEAD ref, due to quourum, during a fetch should not fail
the fetch entirely.
Instead, log the success and failure, or return an error in other cases.
In fact, any failure to set the head could have resulted in notifications not
being sent, nor caching to occur.
Ensure that remote branches can be delete via the `-d` flag. This
includes the fact that one can delete the `refs/heads/patches`
branches, as long as they are owned by the current operator.
Fintan Halpenny
Lorenz Leutgeb
n4ch7
Lars Wirzenius
Lorenz Leutgeb
Sekhat Temporus
Richard Levitte
tippfehlr
Yorgos Saslis
Sebastian Martinez
cloudhead
Arnaud Bailly