Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support --offline flag for check. #357

Closed
adam-azarchs opened this issue Jul 19, 2021 · 1 comment · Fixed by #359
Closed

Support --offline flag for check. #357

adam-azarchs opened this issue Jul 19, 2021 · 1 comment · Fixed by #359
Labels
enhancement New feature or request

Comments

@adam-azarchs
Copy link

Is your feature request related to a problem? Please describe.

Our CI tests run in an isolated (sandboxed) environment with no network access. We run cargo fetch beforehand in order to populate the CARGO_HOME, then run other commands like cargo test with --frozen --offline. This doesn't work for cargo deny at present.

Some reasons why we try to run this way:

  1. Security: not running build.rs scripts with network access.
  2. Reproducibility: if a commit of the repo passes, it should always pass. We don't want network glitches or people deleting their git repository to break builds for old commits (or at least if it does break the build we'd like it to be easy to figure out that that's what happened).
  3. The build machines haven't been set up with credentials to access private registries.

Describe the solution you'd like

Similar to other commands like cargo build, accept the --offline flag to prevent network access. If CARGO_HOME doesn't have everything necessary for the checks, fail.

This flag may or may not imply --disable-fetch for advisories; there may be situations where one wants to avoid network access.

Describe alternatives you've considered

Running cargo deny in a separate environment which isn't restricted from the network. But, this can lead to flaky tests if some external network resource is down at the time the test runs. If CARGO_HOME is already populated, cargo deny shouldn't actually need network access for anything except fetching the advisories database (which could be done in a separate step maybe, but that is out of the scope of this feature request).

There's an argument that this behavior should be the default, and it shouldn't be trying to access the network if it doesn't need to, but most of the cargo commands do seem to engage in mandatory unnecessary network access unless explicitly told not to.

@Jake-Shadle
Copy link
Member

This was actually part of #353 already, but #359 is more complete support for all of the related flags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants