Overview

Delivers ANE-2302.

When we analyze a cargo project, we run cargo generate-lockfile, even if the lockfile already exists.

This can result in changes to the existing lockfile, which is causing builds to fail for at least one customer.

This PR changes the behaviour so that we only run cargo generate-lockfile if the Cargo.lock file does not exist.

Acceptance criteria

• If the Cargo.lock file does not exist, we run cargo generate-lockfile to create it.
• If the Cargo.lock file does exist, we do not run cargo generate-lockfile, and the Cargo.lock file does not get changed.
• In both cases the analysis succeeds

Testing plan

make install-dev
cd <some rust project>
fossa-dev analyze --output

This should not result in any changes to the Cargo.lock file.

delete the Cargo.lock file and run fossa-dev analyze --output again. This time it should create the Cargo.lock file and the analysis should succeed.

Risks

I think that this is low risk

Metrics

References

https://fossa.atlassian.net/browse/ANE-2302

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.