Build tooling to review Cargo.lock bumps #20

New Issue

Open

opened 2024-01-18 21:59:55 +00:00 by ryan · 2 comments

ryan commented

2024-01-18 21:59:55 +00:00

Owner

Given two version of Cargo.lock (base commit, head commit), find out which new versions of packages are added, and run the following steps:

Download a tarball of the old version
Verify tarball using Lockfile
Initialize Git repository, make a commit, based on the existing tarball
Download a tarball of the new version
Verify tarball using Lockfile
Replace working directory with contents of tarball
Add all files to Git staging area
Run git difftool HEAD

Given two version of Cargo.lock (base commit, head commit), find out which new versions of packages are added, and run the following steps: * Download a tarball of the old version * Verify tarball using Lockfile * Initialize Git repository, make a commit, based on the existing tarball * Download a tarball of the new version * Verify tarball using Lockfile * Replace working directory with contents of tarball * Add all files to Git staging area * Run `git difftool HEAD`

ryan commented

2024-01-19 00:16:26 +00:00

Author

Owner

Can use cargo fetch. Implemented via make review.

Can use `cargo fetch`. Implemented via `make review`.

ryan closed this issue

2024-01-19 00:16:26 +00:00

ryan commented

2024-01-26 08:41:07 +00:00

Author

Owner

Reopening because I'm not happy with this. I want a tool that can be used to audit things before or while cargo update is being run, something that allows more interactivity. The ideal workflow would be:

The total list of potential upgrades is acquired
For each potential upgrade, determine:
- The impact of the upgrade
- The amount of dependencies added/forked
If the dependency is approved, run a system similar to make review for each crate to be affected by this change.

make review can still be used by anyone who wishes to review all previously upgraded crates at once, but tooling must exist to streamline the process of choosing what upgrades to include.

Reopening because I'm not happy with this. I want a tool that can be used to audit things before or while `cargo update` is being run, something that allows more interactivity. The ideal workflow would be: 1. The total list of potential upgrades is acquired 2. For each potential upgrade, determine: * The impact of the upgrade * The amount of dependencies added/forked 3. If the dependency is approved, run a system similar to `make review` for each crate to be affected by this change. `make review` can still be used by anyone who wishes to review all previously upgraded crates at once, but tooling must exist to streamline the process of choosing what upgrades to include.

ryan reopened this issue

2024-01-26 08:41:07 +00:00

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: public/keyfork#20

No description provided.