Remove --allow-dirty option (v2) …

[Olf0]

… from cargo publish calls in the CI/CD workflows, because this option prevents creating a .cargo_vcs_info.json file. This should (really) close rust-lang/crates.io#8551 , see there for details.
Now a cargo package with --allow-dirty executes all steps a cargo publish does except publishing, then the changes are committed back to the git repo and lastly cargo publish is run; for details see last paragraph of #702 (comment).

Supersedes PR #702

Signed-off-by: olf [email protected]

[Olf0]

Please squash-merge this PR.

P.S.: It might make sense to publish the .crate file as part of the uploaded files for a release on the Release page. But that would be another PR for the CI/CD YAML files.

[Shnatsel]

Thank you for the PR!

I don't want to skip the verification done by cargo publish because it tests the build with latest dependencies as opposed to the one we have in Cargo.lock. So it is valuable, and the release workflow runs infrequently enough that the time savings don't really matter.

In the longer term this whole workflow needs to be drastically simplifed. Instead of bumping the version by itself and adding a git tag, it should be invoked by a tag being pushed - same as the cargo dist workflow we already have. This both removes a lot of complexity from it, and lets us actually use the cargo dist workflows properly (they aren't triggered by a tag created by another action).

[Shnatsel]

Also, sadly CI requires signoff on individual commits. You can either use git commit --signoff as you create them, or use the command from the DCO CI action to amend them after the fact.

[Olf0]

I don't want to skip the verification done by cargo publish because it tests the build with latest dependencies as opposed to the one we have in Cargo.lock. So it is valuable, and the release workflow runs infrequently enough that the time savings don't really matter.

As this build verification was performed by cargo package two CI steps before, you think they may have changed during the git push etc. (i.e. the "git" CI step)?

As it sure does not make much sense to run the same build test twice within less than a second, I can move the --no-verify to the cargo package call, if you insist. But IMO this is the wrong order: The build test should let the workflow fail early, before the stuff is committed back to the git repo.

In the longer term this whole workflow needs to be drastically simplifed. Instead of bumping the version by itself and adding a git tag, it should be invoked by a tag being pushed - same as the cargo dist workflow we already have. This both removes a lot of complexity from it, and lets us actually use the cargo dist workflows properly (they aren't triggered by a tag created by another action).

Yes, sounds plausible. But is this reasoning just for stating that the whole approach here is dismissed by you?

Also, sadly CI requires signoff on individual commits. You can either use git commit --signoff as you create them, or use the command from the DCO CI action to amend them after the fact.

Without a local git repo I sure cannot run git commit --signoff. But "the command from the DCO CI action" sounds interesting as it may work at GitHub: Where can I find it?

[Shnatsel]

You can find the command here: https://github.com/CycloneDX/cyclonedx-rust-cargo/runs/25402576811

You should be able to run it in Github Codespaces. They are free up to a certain monthly cap, and provide a terminal with the full Git CLI.