embarkstudios / cargo-deny-action Goto Github PK

Wanted to use alpine as as a docker image base, but as cargo-deny requires Cargo to be installed (due to cargo_metadata crate that runs the cargo command) I'm simply using the Rust debian image as base now instead.

If cargo-deny would support linking in Cargo then it would be fully standalone and using alpine would be easy, tracked in EmbarkStudios/cargo-deny#54

May also be able to switch to alpine and just install Cargo to it and the minimal dependencies needed

I tried to use this, but it is not working :/
https://github.com/sile/hls_m3u8/pull/44/checks?check_run_id=461139614

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Device:

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Describe the bug
When you use ssh://[email protected]/org/repo.git inside Cargo.toml to fetch private dependence I got error.

Error: -18 12:35:18 [ERROR] failed to fetch crates:     Updating crates.io index
    Updating git repository `ssh://[email protected]/org/repo.git`
error: cannot run ssh: No such file or directory
fatal: unable to fork
error: failed to get `my-dependency` as a dependency of package `my-package v0.1.0 (/github/workspace)`

Caused by:
  failed to load source for dependency `my-dependency`

Caused by:
  Unable to update ssh://[email protected]/org/repo.git?branch=feat/healtcheck-interface#cc73f02e

Caused by:
  failed to clone into: /usr/local/cargo/git/db/(...)
  
Caused by:
  process didn't exit successfully: `git fetch --tags --force --update-head-ok 'ssh://[email protected]/org/repo.git' '+refs/heads/*:refs/remotes/origin/*' '+HEAD:refs/remotes/origin/HEAD'` (exit status: 128)

job is defined below:

jobs:
  cargo-deny:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        checks:
          - advisories
          - bans licenses sources

    # Prevent sudden announcement of a new advisory from failing ci:
    continue-on-error: ${{ matrix.checks == 'advisories' }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          token: ${{ secrets.PAT }}
          submodules: "recursive"
      - name: Github SSH key setup
        uses: shimataro/ssh-key-action@v2
        with:
          key: "${{ secrets.CI_SSH_PRIVATE_KEY }}"
          name: id_rsa
          known_hosts: github.com
      - uses: EmbarkStudios/cargo-deny-action@v1
        with:
          command: check ${{ matrix.checks }}

Expected behavior
Should just work out of the box or be possible to configure

Additional context:
To make cargo build works inside docker I need to add --mount=type=ssh.

for example:

RUN --mount=type=ssh cargo build --bins --release --workspace

Maybe the issue here is the same

Is your feature request related to a problem? Please describe.
From what I can see, if I add this action to multiple crates I don't seem to be able to have a shared deny.toml which they can all point to. This means any updates would need to be made to each individual deny.toml

Describe the solution you'd like
The ability to point each crate to a shared deny.toml in an arbitrary location, therefore when I want to update the deny.toml I only need to do so in 1 single location and changes take effect across my crates.

Describe alternatives you've considered
I intend to try adding a wget of a shared deny.toml which will run immediately before the action

Additional context

Is your feature request related to a problem? Please describe.
This action appears to be Linux-only for the moment. I discovered this by adding it to a Windows Github Actions workflow. Since cargo-deny takes about 10m to compile on Github Actions, it needs manual caching which is complicated by the fact that actions/cache@v2 cannot use files outside of the repository root as cache keys.

Describe the solution you'd like
Action is updated to support windows.

Describe alternatives you've considered
Installing and caching cargo-deny as part of the workflow. This is complicated and less ideal than the proposed solution.

Thanks for writing and maintaining this action in the first place!

Describe the bug

My Cargo.toml contains the following section

[profile.release]
lto = true
codegen-units = 1
strip = true

in GitHub Actions, use of the cargo-deny-action throws the following error:

Error: -03 17:04:24 [ERROR] `cargo metadata` exited with an error: error: failed to parse manifest at `/github/workspace/Cargo.toml`

Caused by:
  feature `strip` is required

  The package requires the Cargo feature called `strip`, but that feature is not stabilized in this version of Cargo (1.58.0 (f01b232bc 2022-01-19)).
  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-strip-option for more information about the status of this feature.

Expected behavior

I expected the cargo-deny action to run without error

Device:

• ubuntu-latest

Whether a cargo-deny check succeeds or fails, doesn't entirely depend on the contents of a commit. e.g. new advisory could be released and make previously passing commits fail.

Therefore, it's a better idea to schedule the advisory checks based on a schedule, instead of per-commit, and open issues to notify the developer when checks fail.

Describe the bug
When my cargo project has a private git repository defined, cargo deny action will fail. Please add possibility to provide a personal access token for git usage.

To Reproduce
Steps to reproduce the behavior:

1. Create cargo crate which references a private git repository
2. Configure deny as usual (defaults are enough)
3. Run 'cargo deny --log-level warn --all-features check bans licenses sources'
4. Fails with:

[ERROR] `cargo metadata` exited with an error:     Updating crates.io index
    Updating git repository `[https://github.com/private-repo`](https://github.com/private-repo%60)
error: failed to get `private-repo` as a dependency of package `...`
Caused by:
  failed to load source for dependency `private-repo`
...

My action.yaml

deny:
    name: Deny
    runs-on: ubuntu-latest
    strategy:
      matrix:
        checks:
          - advisories
          - bans licenses sources
    # Prevent sudden announcement of a new advisory from failing ci:
    continue-on-error: ${{ matrix.checks == 'advisories' }}
    steps:
      # checkout this repository
      - name: Checkout
        uses: actions/checkout@v2
      # checkout my private repository - just to show that it works
      - name: Checkout
        uses: actions/checkout@v2
        with:
          repository: private-repo
          path: tmp
          ref: master
          token: ${{ secrets.USER_PAT }}
      - name: Deny
        uses: EmbarkStudios/cargo-deny-action@v1
        with:
          command: check ${{ matrix.checks }}

Expected behavior
deny should run and check as "normal" and provide its results. It woks also locally using gits credential-helper=store. Please support option to pass token/credentials to cargo-deny-action.

The version on GitHub Action Marketplace for this action is v1.2.1, which lags behind the actual release (v1.5.4 right now).

Describe the bug

https://github.com/djc/corda-rpc/actions/runs/283774748

2020-10-02 06:50:00 [ERROR] failed to load advisory database: parse error: unexpected character found: ``` at line 1 column 1

Describe the bug
In github actions, you can set the default folder from which all actions should be run.
example:

name: CI
on: [push, pull_request]
defaults:
  run:
    working-directory: ./rust-app
jobs:
  cargo-deny:
    runs-on: ubuntu-22.04
    steps:
    - uses: actions/checkout@v3
    - uses: EmbarkStudios/cargo-deny-action@v1

However, this action does not respect the default folder and instead runs from the root directory of the repo.

here is an example repo / workfow:

https://github.com/ctriley/cargo-deny-example/actions/runs/7349611506/job/20009854868

Is your feature request related to a problem? Please describe.
This action internally uses a container with a fixed stable Rust release. However, as the maintainer of a Rust project that uses nightly features in its Cargo.toml manifest, I'd appreciate the action to be also fully compatible with nightly Rust projects.

Moreover, although this project looks well-maintained enough to bump the Rust version, in the future someone could be using a feature that is not supported in the hardcoded Rust version at the time, and the inability to readily change it may be a blocker or a turn-off.

Describe the solution you'd like
An action input parameter to select the Rust version that is used in the container to run commands such as cargo metadata, which cargo deny needs to function.

Describe alternatives you've considered

• Not using nightly Rust, or only using the features supported by the hardcoded Rust version. However, that is not always practical.
• Forking the project to tweak the Dockerfile as needed. I've done so out of necessity, but it's an ugly workaround in any case.
• Changing how cargo deny works so that it doesn't rely on Cargo being installed at all. I've no idea of how complicated this would be, but it definitely doesn't look like a piece of cake.

Additional context
I don't have any additional context to describe.

Hi,

I was planning to use this action but noticed it works only on Linux (since it's a docker container) and I'm wondering if it makes any sense to run it on macOS and Windows (I had a matrix build and used cargo-deny from crates.io previously).

Or maybe cargo-deny doesn't depend on any target OS and I just should use this action on Linux and that's it?

Thanks for clarifying and, of course, for this excellent piece of software! 👋

Describe the bug

Recently, my CI builds have failed with

2020-05-16 15:38:32 [ERROR] unable to find metadata section in Cargo.lock

It sounds like this is EmbarkStudios/cargo-deny#56, but as far as I can tell, this has been resolved & a release published months ago (plus, the same code did run the action correctly before).

To Reproduce

• cargo deny config: https://github.com/antifuchs/governor/blob/6eec6f36058faedc5b0be3228d65f7eb8191906d/deny.toml
• github ci setup: https://github.com/antifuchs/governor/blob/6eec6f36058faedc5b0be3228d65f7eb8191906d/.github/workflows/cargo_deny.yml

Expected behavior
I would expect cargo deny to correctly parse my Cargo configuration and probably tell me some crate configs are wrong.

CI runs

Here's a failed run: https://github.com/antifuchs/governor/runs/681094137

Additional context / attempt at diagnosis

It looks like this is trying to use the 0.4.2 version of cargo deny: https://github.com/antifuchs/governor/runs/681094137#step:2:30 - but the Dockerfile pulls in 0.6.7! Is something wrong with the way the github action is configured, or is github itself having a hiccup there?

I have a project where there is no Cargo.toml at the repository root (all the Rust stuff is in a subdirectory).

I've tried this:

jobs:
  cargo-deny:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: api
    steps:
      - uses: actions/checkout@v2
      - uses: EmbarkStudios/cargo-deny-action@v1

but it doesn't work (seems like defaults.run doesn't apply to cargo-deny-action).

Is there some way to do this with cargo-deny-action as-is, or would this be a new feature?

Describe the bug

Error: -17 09:39:39 [ERROR] `cargo metadata` exited with an error: error: failed to parse manifest at `/github/workspace/Cargo.toml`

Caused by:
  feature `strip` is required

  The package requires the Cargo feature called `strip`, but that feature is not stabilized in this version of Cargo (1.58.0 (f01b232bc 2022-01-19)).
  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-strip-option for more information about the status of this feature.

So basically the container use old version of cargo. This could be fixed by scheduling build new image every time new stable rust is released. Dockerfile make sure it's up to date when building

source of error: https://github.com/xoac/signer-flow/runs/5583604418?check_suite_focus=true

The cargo-deny action cannot access private repos on github as crate dependencies without git installed in the container. See: EmbarkStudios/cargo-deny#367

This github action should take advantage of the annotations feature for making it easier for users to find the issues when the action fails. I think if the Cargo.toml is present in the diff then you can add the annotation there. If it is not it could just be appended to the end of the diff.

A good reference is the https://github.com/actions-rs/clippy-check action which uses this feature.

This is a tracking issue of what is needed to publish a first v1 version. When it is published it will show up in the GitHub marketplace for everyone which is nice for discoverability.

Primarily right now need to test it on more repos to see if it behaves well, and look into performance / build times.

To support the much needed exclude-dev option.

A simple typo here: https://github.com/EmbarkStudios/cargo-deny-action/releases/tag/v1.2.10

It says "1.2.20" in the headline when it should say 1.2.10.

Looks like it takes around 1 min for GitHub (example) to build the current docker image that we use, and even more importantly; it does it every time for every repo that uses this action - which is not ideal.

Would have expected GitHub to cache that if it is from the same version or revision of an action, maybe that is not implemented yet?

What we could do however is to build and publish a docker image from this repo and refer to that instead in the action. Requires a bit more set up however when versioning, but should be doable. Alternatively can have the cargo-deny repo itself build and publish the images and simply just use the right one here in the action, that is likely the cleanest

This Github action tends to lag a bit behind the original core cargo deny repo.
I suggest setting up a Github workflow that automatically updates this action, upgrades the version, and publishes a new tag.

Describe the solution you'd like
We might use a repository-dispatch trigger for a workflow in this repository. The original repo will just POST an event with the version number and the workflow will respond to that event bumping the version of the action and cargo-deny

Describe alternatives you've considered
We might move action code to the core repo so it is much easier to keep it in sync, but this will have some drawbacks, as the tags for the action and cargo-deny tool may be in conflict. In fact, this seems improper that the action is already at 1.0.0+ version, but the underlying tool is still <1.0.0, which is a separate topic I guess (cc @repi)

I am using cargo-deny in most of my open source repositories these days. However, when the job completes without warnings or errors, there is no explicit output. It would be nice to print some affirmative summary that the analyses were completed.

Could be something like:

ran checks licenses, sources, vulnerabilities, bans: 0 errors, 0 warnings

It just happened when running CI in a PR, here is the log: https://github.com/Byron/gitoxide/actions/runs/7884315019/job/21513814089?pr=1288 .

Since I changed nothing about it and the setup is standard, I assume something changed here and just wanted you to know this is happening.
Here is a link to deny.toml for completeness.

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

Locally, cargo deny already colorizes the output. However, the GitHub action doesn't.

Describe the solution you'd like

Would be very nice if the action could always colorize the output automatically. It seems like this just requires passing --color always to cargo deny.

I encountered a failure in a CI job this morning:

Run EmbarkStudios/cargo-deny-action@v1
  with:
    rust-version: 1.75.0
    log-level: warn
    command: check licenses bans advisories
    arguments: --manifest-path rust/Cargo.toml
    manifest-path: ./Cargo.toml
/usr/bin/docker run --name ca062eae54cac7991f4f5bb0f8ad0c91706ff9_5807cf --label ca062e (...)  "1.75.0" "" "--log-level" "warn" "--manifest-path" "./Cargo.toml" "--manifest-path rust/Cargo.toml" "check licenses bans advisories" ""
info: profile set to 'minimal'
info: syncing channel updates for '1.75.0-x86_64-unknown-linux-musl'
info: latest update on 2023-12-28, rust version 1.75.0 (82e1608df 2023-12-21)
info: downloading component 'cargo'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: installing component 'cargo'
info: installing component 'rust-std'
info: installing component 'rustc'
info: default toolchain set to '1.75.0-x86_64-unknown-linux-musl'

  1.75.0-x86_64-unknown-linux-musl installed - rustc 1.75.0 (82e1608df 2023-12-21)

error: the argument '--manifest-path <MANIFEST_PATH>' cannot be used multiple times

Usage: cargo-deny [OPTIONS] <COMMAND>

For more information, try '--help'.

I see that the release notes say:

• Added the manifest-path key as a shorthand for doing arguments: --manifest-path

But it's not clear to me whether that release was intended to break the old usage.

I also (incorrectly?) assumed that by pinning to cargo-deny-action@v1 that I wouldn't experience breaking changes.

To Reproduce

jobs:
  cargo-deny:
    runs-on: ubuntu-22.04
    steps:
    - name: Checkout
      uses: actions/checkout@v3
    - name: cargo deny
      uses: EmbarkStudios/cargo-deny-action@v1
      with:
        rust-version: "1.75.0"
        log-level: warn
        command: check licenses bans advisories
        arguments: --manifest-path rust/Cargo.toml

Expected behavior
I expected cargo-deny-action@v1 to keep working, even though my job uses the old arguments: --manifest-path syntax.