Automated publishing based of the releases in cargo-deny core repo

[Veetaha]

This Github action tends to lag a bit behind the original core cargo deny repo.
I suggest setting up a Github workflow that automatically updates this action, upgrades the version, and publishes a new tag.

Describe the solution you'd like
We might use a repository-dispatch trigger for a workflow in this repository. The original repo will just POST an event with the version number and the workflow will respond to that event bumping the version of the action and cargo-deny

Describe alternatives you've considered
We might move action code to the core repo so it is much easier to keep it in sync, but this will have some drawbacks, as the tags for the action and cargo-deny tool may be in conflict. In fact, this seems improper that the action is already at 1.0.0+ version, but the underlying tool is still <1.0.0, which is a separate topic I guess (cc @repi)

[repi]

Thanks for filing! Agree that this has been a problem.

Easiest solution would be for @Jake-Shadle and me to just everytime we publish a new cargo-deny version do publish this action also, directly after, it is an extra manual step but it is very easy to publish this action as it is a single commit to change the hash and then push the tags (update v1 and add a specific v1.0.x). Assuming the change is fully compatible which is something one should consider as part of the cargo-deny release process anyway.

Based on this compatibility I would be somewhat vary of an automatic solution here.

Describe alternatives you've considered
We might move action code to the core repo so it is much easier to keep it in sync, but this will have some drawbacks, as the tags for the action and cargo-deny tool may be in conflict

Did consider this initially and ideally would want the action to be in the same repo to make things easier, not a fan of tiny separate repos but that is how GitHub likes it for actions and it would indeed be somewhat problematic and non-standard with the tags if one had it in the main repo, not to mention that you have to do a commit to update the dockerfile executable hash to point to a previous release in the same repo (which is not different than now, just a bit odd in to do in the sam repo).

One could call the tag action-v1 and refer to it as cargo-deny@action-v1 but is less standard and also this action and repo is published in the GitHub marketplace, though likely could shut that down and publish cargo-deny instead.

But think it likely is easiest to keep this separate, but just require that every time we publish cargo-deny version, the person that publishes it (usually @Jake-Shadle ) has to publish an updated action also.

[Veetaha]

Well, seems convincing, not everything should be automated, I guess