Implement shared workflows

[bstrie]

Github supports sharing workflows between repos in an organization:

https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/reusing-workflows

https://docs.github.com/en/enterprise-cloud@latest/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise

Make a list of workflows that should be shared among multiple repos (commit message checker, license checker, cargo clippy, cargo fmt, dependabot, etc.) and implement them as shared workflows so that we can avoid duplicating them across every repo.

Candidates for shared workflows:

• [Feature] Implement shared commisery workflow. #50
• automerge
• dependabot
• [Feature] Implement project management automation #46
• spdx-headers
• copy labels
• Implement cargo related shared workflows #54
• cargo clippy
• cargo-deny
• cargo test (do last, make sure it depends on the success of the above, takes time and done against a matrix)

The first step for each of these is to define them as shared workflows in this repo. Once that is done, we should go through every other repo and reference the workflows from any repo that wants to use these.

[dpal]

I am taking over this ticket.
The strategy is:

• Create all the needed shareable workflows in the .github repository (test them in a separate organization)
• Use the "noted" repo as the first repo to convert to shared workflows. Make sure that everything is polished.
• Replicate the same configuration/cleanup for other repositories while also cleaning the old unused workflows.

[bstrie]

Feel free to tag me as the reviewer for all of these PRs.

[dpal]

@bstrie I started working with my test organization and repeated the example with the commisery. However, I think I found an issue in your approach. As written the rules do not apply to the .github repo when one creates patches for it. So we need different files in the workflows directory in the repo:

• files with the reusable workflows
• files using the reusable workflows for that repository

Also, I played with the automerge. I found this:
https://github.com/marketplace/actions/merge-pull-requests-automerge-action
But I am not sure this is what we want.
We do not want to have to create labels. It is more complex than clicking the button once all checks are done.

This brings a different question.
How do we know which implementation for the action to choose?
If it comes from there github - OK. But what if it comes from some other place?
How do we know it is a trustworthy and maintained place?
Do we look at the stars of the repo?
Do we create a fork and use our own copy?
What would be the strategy?

[dpal]

Next steps:

• investigate if shared workflows can be moved to a subdirectory
• use enarx repo as a reference point for the workflow implementations
• start with non-cargo ones
• figure out tokens and secrets needed/expected

[rvolosatovs]

Refs #37 #36