`generate-lockfile` overwrites a checked-in Cargo.lock

Description

I have a repo where I’ve checked in Cargo.lock, since it’s producing a binary which I’m shipping. I’ve just started getting audit violations in CI for this that I cannot reproduce locally. I’ve tracked this down to the generate-lockfile call at the beginning; this updates the checked-in Cargo-lock. In my case, it brings in a new vulnerability due to a transitive dependency update.

Workflow code

name: Security audit
on:
  push:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
jobs:
  security_audit:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Expected behavior

If a Cargo.lock is in source control, it should be used as-is.

[Nemo157]

Rather than generate-lockfile this should call cargo metadata --format-version=1 >/dev/null as a relatively quick no-op “ensure the lockfile is up to date”. It would be good for the action to also take a locked: boolean flag to determine whether to pass --locked to this call for repositories that expect the lockfile to always be up to date.

[eugene-babichenko]

Another problem this behavior incurres:

• Let’s say we have a Cargo.lock that works perfectly fine.
• It has a dependency (in my case transitive) that is yanked from the crates.io registry but still downloadable.
• Due to how yanked crates work cargo generate-lockfile just will not be able to create Cargo.lock.

And it doesn’t need to, because a working Cargo.toml is already there.