| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
| |
We no longer need a path to a checkout of the chutney repository; we
just need the chutney binary itself. We still allow this to be set
explicitly with CHUTNEY_BIN, but fall back to finding it on the PATH.
|
| |
|
|
|
|
|
|
| |
This takes advantage of a feature added in
https://gitlab.torproject.org/tpo/core/chutney/-/merge_requests/31.
This is a step towards not needing to set CHUTNEY_PATH to point to a
chutney repository.
|
| |
|
|
|
|
| |
The `black` formatter did most line wrapping for us, and we accept
its default of 88 characters there, but for comments and docstrings
(which black doesn't wrap) we allow up to 99 characters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Black" is an "opinionated" python formatter, whose opinionatedness
is somewhat in the spirit of rustfmt.
This MR runs black with default settings on all of our python code
in Arti. It was produced by the following commands
```
# Everything in python/
black python/
# Everything with a .py extension
fd '.py$' -X black
# Everything with a python shebang.
git grep -l '#! */usr/bin/env *python' | xargs black
```
|
| |
|
|
|
| |
This is a wrapper script for running `tests/chutney/integration-e2e`
under shadow.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously `tests/chutney/setup` would locate *or install* chutney and
set `CHUTNEY_PATH` for itself. However that `CHUTNEY_PATH` wasn't
propagated to other steps or "up" to the new `integration-e2e` wrapper
script.
Tracking it in the arti.run along with other dynamic info lets us ensure
we consistently use the same chutney across steps, and in the higher
level `integration-e2e` script.
|
| | |
|
| |
|
|
|
|
| |
It looks like it changed at some point. Rather than hard-coding,
just do the lookup locally and compare the tor-lookup result against
that.
|
| |
|
|
|
|
|
| |
Having this in a script is a step towards being able to run exactly the
same test under shadow without duplicating this high-level logic.
It's also convenient for running the ci test locally.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This commit changes the shebang in all shell scripts from absolute
paths (such as `/bin/bash` or `/usr/bin/python3`) to the `/usr/bin/env`
binary with the accompanying interpreter as it's argument.
The reason for this are as follows:
- NixOS cannot work with absolute paths
- BSD systems install their packages in /usr/local/bin
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Apparently 5353 is commonly used for mDNS, and so counts as "already in
use" on many consumer machines.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It turns out that the clone-and-hack in tests/chutney/arti-bench
was not identical to the original in tests/chutney/setup.
I diffed the two and preferred the version from arti-bench.
|
| |
|
|
|
|
|
|
|
| |
Formerly, the "launch a chutney network" code was duplicated in
"setup" and "arti-bench", since "setup" always launched an arti
proxy, while "arti-bench" didn't want that functionality.
Now the "setup" script launches an arti proxy conditionally,
depending on whether the "proxy" argument is given.
|
| |
|
|
|
| |
This is not a replacement for a real startup protocol, but it may
help repair our CI.
|
| |
|
|
| |
Now that arti listens immediately, a very short sleep ought to do.
|
| |
|
|
|
|
|
|
|
| |
As per #309
Update all references. There is one remaining hit for
git-grep '\.sh\b'
namely "build.sh" in maint/reproducible_build, which I think is
the build script for osxcross - ie, an external project.
|
| |
|
|
|
| |
This adds `arti-bench` to the `integration` job in the CI pipelines, and
keeps around the JSON benchmark output for later comparison.
|
| |
|
|
| |
Rationale: It's good to have all of our scripts pass shellcheck.
|
| |
|
|
|
| |
Previously, this case would cause arti-bench to hang forever, trying
to bootstrap against one network while another network was running.
|
| |
|
|
| |
(An empty $RUST_LOG no output, and confuse the nickm^Wuser.)
|
| |
|
|
|
| |
shellcheck doesn't like `export FOO="$(bar)"` as one line, since it
has the possibility of missing errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new `arti-bench` crate does a simple end-to-end benchmark test
embedding Arti: it generates some random data (of configurable amount,
depending on command-line parameters), and then sends said data back and
forth via Arti (which should be configured to use a local Chutney
network).
Additionally, the benchmark can also be run via a local SOCKS5 server
(in order to benchmark the performance via a local Chutney node, for
comparison).
The `tests/chutney/arti-bench.sh` sets up and tears down Chutney as
required to make this work.
This is very much a first cut; there are many things that should
eventually get added, such as support for multiple connections, JSON
output capabilities, running multiple tests, ...
|
| |
|
|
| |
This is per a suggestion from @trinity-1686a.
|
| |
|
|
|
| |
Previously, if the arti process had died or been killed, we wouldn't
reach the point where we called "chutney stop".
|
| |
|
|
|
|
|
|
| |
If the user has CHUTNEY_PATH set, respect that value, rather than
cloning a local chutney.
Also, if we have a local chutney, then update it in case there have
been changes.
|
| |
|