You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a project that uses cargo-bundle-licenses to bundle the licenses for all of its third-party dependencies, and this same project has Dependabot version updates enabled for all dependencies (both direct and indirect). As a result, every Monday, a pull request is automatically created in the project repository updating the versions of some number of dependencies, usually only touching the lockfile. Per cargo-bundle-licenses' recommendation, I have also configured GitHub Actions to run cargo bundle-licenses --check-previous -o CI.toml -p THIRDPARTY.toml on every push & PR.
As a result, whenever Dependabot opens one of its PRs, the CI fails because the changes to dependency versions made the --check-previous command exit nonzero. On the one hand, this is good, as it reminds me to update the THIRDPARTY.toml file. On the other hand, this is annoying, as I have to manually update the file locally despite an up-to-date license bundle having been generated in CI.
Here's my dream for how this should work instead:
Whenever a PR is opened or updated that modifies dependencies, cargo-bundle-licenses is run in CI to regenerate THIRDPARTY.toml, and the changes are committed & pushed. (If it's a Dependabot PR, the commit message should include "[dependabot skip]" so that Dependabot can still do automatic rebasing.)
The CI automation posts a comment on the PR listing all changes made to THIRDPARTY.toml: changes in packages listed, changes in package versions, changes in license expressions, and changes in license text. If one or more licenses weren't found, this is noted in bold letters.
The CI job should only fail if a license was not found. I guess it could also be configured to fail if the confidence in some license text falls below a given threshold, but I don't think I'd be using that feature.
I'm not asking or requiring you to help me fulfill this dream, but I'd be nice if you did. I just want you to be aware that the developer experience around keeping my THIRDPARTY.toml up-to-date could stand to be improved.
The text was updated successfully, but these errors were encountered:
These are great points. I've also found the workflow with cargo bundle-licenses to be lacking, but haven't been working on anything that uses it in a while. That may be changing sometime soon though. In the meantime I continue to welcome all PRs and really appreciate the work you've already put in here.
I have a project that uses
cargo-bundle-licenses
to bundle the licenses for all of its third-party dependencies, and this same project has Dependabot version updates enabled for all dependencies (both direct and indirect). As a result, every Monday, a pull request is automatically created in the project repository updating the versions of some number of dependencies, usually only touching the lockfile. Percargo-bundle-licenses
' recommendation, I have also configured GitHub Actions to runcargo bundle-licenses --check-previous -o CI.toml -p THIRDPARTY.toml
on every push & PR.As a result, whenever Dependabot opens one of its PRs, the CI fails because the changes to dependency versions made the
--check-previous
command exit nonzero. On the one hand, this is good, as it reminds me to update theTHIRDPARTY.toml
file. On the other hand, this is annoying, as I have to manually update the file locally despite an up-to-date license bundle having been generated in CI.Here's my dream for how this should work instead:
Whenever a PR is opened or updated that modifies dependencies,
cargo-bundle-licenses
is run in CI to regenerateTHIRDPARTY.toml
, and the changes are committed & pushed. (If it's a Dependabot PR, the commit message should include "[dependabot skip]" so that Dependabot can still do automatic rebasing.)The CI automation posts a comment on the PR listing all changes made to
THIRDPARTY.toml
: changes in packages listed, changes in package versions, changes in license expressions, and changes in license text. If one or more licenses weren't found, this is noted in bold letters.The CI job should only fail if a license was not found. I guess it could also be configured to fail if the confidence in some license text falls below a given threshold, but I don't think I'd be using that feature.
I'm not asking or requiring you to help me fulfill this dream, but I'd be nice if you did. I just want you to be aware that the developer experience around keeping my
THIRDPARTY.toml
up-to-date could stand to be improved.The text was updated successfully, but these errors were encountered: