Cargo set-version --workspace does not update Cargo.lock with private crate reference

[brogdonm]

Apparently, when using the cargo set-version --workspace command in GitHub actions using a linux runner, the Cargo.lock file does not get updated with the updated version. When running on Windows, my WIP has a Cargo.toml and Cargo.lock change. In our scenario, the repository using the action is setup to use workspaces.

Update:
Apparently, the issue recreates for windows-latest runners too. I could only recreate the issue in my sample repository once I added a private crate.

This is with the latest version: 0.12.2

[epage]

Can you provide local reproduction steps?

[brogdonm]

I setup a repository that demonstrates the issue. Check out the actions to see what I'm talking about:

• First action where it is failing to update Cargo.lock: https://github.com/brogdonm/cargo-edit-issue-891/actions/runs/8637628362/job/23680249988

Turns out, it fails on windows-latest too and from my steps of setting up a simple repository to recreate it appears to happen when there is a crate dependency that is "private".

For example, this fails: brogdonm/cargo-edit-issue-891@fa566e1

This does not: brogdonm/cargo-edit-issue-891@6da6ddc

[epage]

Can you provide local reproduction steps. Meaning without the use of an action

[brogdonm]

Yes...

• Open PWSH on Windows

• Start wsl

  wsl

• From the WSL session:

  brogdonm@localhost:~/src$ git clone https://github.com/brogdonm/cargo-edit-issue-891
  brogdonm@localhost:~/src$ cd cargo-edit-issue-891/
  brogdonm@localhost:~/src/cargo-edit-issue-891$ cargo set-version 0.2.0 --workspace
  brogdonm@localhost:~/src/cargo-edit-issue-891$ git status
  On branch main
  Your branch is up to date with 'origin/main'.
  
  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
          modified:   Cargo.toml

[brogdonm]

When I was originally on Windows running locally, I was not using bash.exe as the windows-latest runner is in the referenced GH workflow, so I assume it is some weird interaction with the bash.

[epage]

When I ran this I got

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   Cargo.toml

no changes added to commit (use "git add" and/or "git commit -a")

$ git diff
diff --git i/Cargo.toml w/Cargo.toml
index a3f8e69..2429eff 100644
--- i/Cargo.toml
+++ w/Cargo.toml
@@ -3,7 +3,7 @@ resolver = "2"
 members = [ "cargo-edit-issue-891" ]

 [workspace.package]
-version = "0.1.0"
+version = "0.2.0"
 authors = [ "Michael Brogdon <Michael.Brogdon@monotype.com>" ]
 description = "A workspace for reproducing cargo-edit issue 891"
 edition = "2021"

$ cargo check
    Updating git repository `https://github.com/brogdonm/private-crate`
error: failed to get `private-crate` as a dependency of package `cargo-edit-issue-891 v0.2.0 (/home/epage/src/personal
/dump/cargo-edit-issue-891/cargo-edit-issue-891)`

Caused by:
  failed to load source for dependency `private-crate`

Caused by:
  Unable to update https://github.com/brogdonm/private-crate?branch=main#f33c4b65

Caused by:
  failed to fetch into: /home/epage/.cargo/git/db/private-crate-2edb19a8c0a6874c

Caused by:
  failed to authenticate when downloading repository

  * attempted to find username/password via git's `credential.helper` support, but failed

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  failed to acquire username/password from local configuration

cargo-set-version was able to update the workspace.package.version field but not the lockfile. However, no cargo commands can update the lockfile; cargo-set-version just fails silently about it.

If this is what you are seeing, I'm not sure what there is we can do about this.

[brogdonm]

@epage first off, thanks for your prompt replies and help. Second off, yes, this is what I'm seeing.

It seemed like this was an issue with the crate since I'm just attempting to update the version of the local crate. Even if I add --offline things do not work as expected or in the same manner as a crate without a private crate listed.

Should this issue be filed with a different crate perhaps? If so, which one does the issue belong with?

[epage]

From what I understand, there is no bug to fix. Cargo itself requires everything in the lockfile to be accessible. Usually that means from the original source while --offline means "only with local caches". If it isn't cached and the source isn't available, there is nothing cargo can do at this time and there is nothing cargo-set-version can do.

[brogdonm]

@epage would it be possible to produce an error? The silence is deafening. :)

If I do cargo update --workspace I get an error indicating the crate can't be accessed.

In the meantime, we will work around this by making sure we have the token in place for access. Thanks for your support.

[epage]

#819 is when we first adopted the code that calls into cargo and falls back silently if the lockfile could not be generated. At that time, it was being used in more general code before we adopted it to also force generation of the lockfile.

I remember needing to do this for a reason but I don't recall the reason and not seeing any notes. I'm assuming erroring for the lockfile generation should be fine though.

As I have priorities elsewhere at the moment, I likely won't get to it for a bit but would gladly accept a contribution that changes the lockfile generation code to pass the error up.

btw so far I've seen little interest in this tool and so I haven't been putting much attention to it generally. For example,, no one has initiated the conversation on the cargo repo on whether this should be merged into cargo like cargo add, cargo rm, and soon cargo upgrade.