| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
| |
This tests ntor_v3 in the shadow integration test.
|
| |\
| |
| |
| |
| | |
Increase our MSRV to 1.70
See merge request tpo/core/arti!1773
|
| | | |
|
| |/
|
|
|
|
|
| |
We were missing `-p arti` in the build command. As a result we were
getting the union of all features requested by anything in the
workspace, including an example enabling the `experimental` feature
which enables a bunch of other things.
|
| | |
|
| |
|
|
| |
otherwis it fails when it gets scheduled on a non-ipv6 ready runner
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a new runner, and apparently to use it better we want to
remove these tags.
TBH this seems rather unprincipled. In theory, shouldn't we tag with
`amd64` all the jobs that we definitely want to run on that arch, and
the others can run on whatever is the default? Then in the glorious
distant RISCV future everything will run on riscv64 by default? But
maybe we wouldn't want to switch that as part of the infrastructure
anyway?
Anyway, for discussion see
https://gitlab.torproject.org/tpo/tpa/team/-/issues/41295#note_2943129
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Workaround for https://github.com/shadow/tgen/issues/44
|
| |
|
|
|
|
|
|
| |
Thesee jobs are ones which don't interact with our Rust executables.
Since `debian:stable-slim` has already been updated I believe, I think
this actually makes no difference right now. But it will prevent us
unexpectedly picking up Debian updates.
|
| |
|
|
|
| |
`rust:latest` updates to a new Debian willy-nilly, which broke our CI
due to it being an uncontrolled dependency.
|
| |
|
|
|
|
| |
This avoids us trying to run binaries built on one image, on a
different one. I believe that this is supposed to work according to
Rust doctrine, but empirically it doesn't.
|
| |
|
|
|
| |
Debian's pip3 now apparently complains when root is running it,
which breaks our old coverage CI.
|
| |
|
|
|
|
|
| |
This was added in 9357a8fd6b22 "ci: add shebang to the GitLab CI" as
part of !990 to the `maint-checks` job; but the actual additional
check was added to the `doc-features` job (by mistake, fixed in
!1490); and, that shebang check script doesn't need git anyway.
|
| |
|
|
|
|
|
| |
Currently, the shebang check CI is not executed, as it would need to
fail then.
See !1489
|
| | |
|
| |
|
|
|
| |
Looks for any checked-in Cargo.lock files, and checks the lockfile
quickly by running `cargo tree --locked` there.
|
| | |
|
| |
|
|
|
| |
`onion-service-client` is now a default feature, so we don't need to
explicitly enable it anymore.
|
| |
|
|
|
|
|
| |
This is needed for testing `experimental-api` features (such as the
keymgr) in shadow and chutney.
Prompted by this discussion: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1399#note_2921294
|
| | |
|
| |\
| |
| |
| |
| | |
CI: extend shadow test to test an onion service connection
See merge request tpo/core/arti!1292
|
| | |
| |
| |
| |
| | |
The shadow test needs this to use this build when testing onion
services.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
I think we do actually do this as part of the coverage job, but that's
not really very clear (and getting the report in that job may be
annoying).
We also do it on nightly as part of the nightly test, but that's an
"allow_fail".
|
| |
|
|
|
|
|
|
| |
These are available in our MSRV now, so we don't need to handle
specially. We can just add them to the standard lint block.
(Lint block in every crate will be updated automatically in the next
commit.)
|
| |
|
|
| |
Since it passes now.
|
| | |
|
| |
|
|
|
|
|
|
| |
This test is known to fail "when the load is high". Recently I had to
press the "merge unverified changes" button to merge !1238, after four
consecutivew spurious failures.
IMO this is intolerable.
|
| | |
|
| | |
|
| |
|
|
| |
Now that we require 1.65, Rust 1.63 is no longer sufficient.
|
| |
|
|
|
| |
Recently we had some minor awkwardness due a new advisory.
This may help in future.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is a fair amount of manual work to keep in sync. I would like to
disable this, at least as a mandatory check, for now.
Fixes #601 (the request for it to become non-blocking).
The underlying issue is #581 and remains open.
Co-authored-by: trinity-1686a <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces all occurrences of `llvm-tools-preview` with
`llvm-tools`, because it became a stable feature with Rust 1.60, thereby
making the `-preview` prefix obsolete. Beside this, `llvm-tools-preview`
is a redirection to the latter one anyway.
However, it does not work the other way around. At the moment, it is not
possible to execute the `maint/coverage` script on a NixOS system,
because the rustup component list only includes `llvm-tools`, but not
`llvm-tools-preview`, thereby making this change necessary.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that they have merged
https://github.com/rust-lang/rust/pull/104416 ,
our CI should pass again with the regular nightly image.
Rather than remove the pinned image entirely, I'm commenting it out,
with a comment explaining how to pin an image the next time we need
to do so.
Closes #633.
|
| |
|
|
| |
This is a workaround for #633.
|