Dependencies workflow runs when example is added

[Person-93]

What problem does this solve or what need does it fill?

The Dependencies github workflow runs when a Cargo.toml is modified even if there were no changes to the dependencies. This caused CI to fail when I happened to add an example shortly after a dependency was deprecated.

What solution would you like?

Commit the Cargo.lock (as per official recommendation) and run the workflow when that file changes instead of Cargo.toml.

For completeness, maybe add a workflow to ensure that Cargo.lock is up-to-date.

What alternative(s) have you considered?

Leave as is.

[mockersf]

We don't want to commit the lock file to be able to test the latest versions of our dependencies (as per official recommendation)

[Person-93]

We don't want to commit the lock file to be able to test the latest versions of our dependencies (as per official recommendation)

Would dependabot be sufficient?

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates
https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates

[mockersf]

We already have Dependabot setup on the repo...
With the number of dependencies Bevy has, that would be a pain to have to merge PRs for every patch of every dependency...

[Person-93]

We already have Dependabot setup on the repo... With the number of dependencies Bevy has, that would be a pain to have to merge PRs for every patch of every dependency...

Dependabot supports grouping multiple updates into one PR. https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--

They can all be included in one PR.

[mockersf]

That would still be more than what we get currently.

Committing the lock files for libraries is good for the library, but not for its users as the lock file is not propagated to them. It just gives a false sense of security in CI.

[Person-93]

That would still be more than what we get currently.

If this is the blocker, then it can be set to merge automatically if all tests pass. This would the same amount of testing that it gets currently except that it wouldn't block unrelated PRs.

Committing the lock files for libraries is good for the library, but not for its users as the lock file is not propagated to them. It just gives a false sense of security in CI.

I don't see how it affects users at all, in a good way or a bad way. Who is getting the false sense of security here? Maintainers of bevy know better, and end-users who care enough to check would probably know better too.

[Person-93]

I thought this was blocking open PRs. My mistake. Sorry about that.