feat: add abstract workflows for coverage, linting, testing, reuse, and scorecard

[seantronsen]

Description

Please include a summary of the change and which issue is fixed.
Also include relevant motivation and context.

Fixes #27, #28, #29, #30

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• I have updated the relevant documentation (CLI examples, man pages, README, other docs, etc.)
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Dependency update
• Build system/CI

---

• I agree to follow the Code of Conduct.

[synackd]

Largely looks good, thanks for the contribution!

Just a couple of small things and improvement ideas.

[synackd]

I didn't see a way to do this in the official REUSE action, but it's nice to be able to see which files are non-compliant. I managed to do this in the ochami CLI with a more manual approach if you'd like to reference it. See:

https://github.com/OpenCHAMI/ochami/blob/main/.github/workflows/reuse.yaml

[seantronsen]

c64b0b9

[synackd]

Wondering if we should allow overriding the REUSE version and default to 6.2.0.

[seantronsen]

I worry that will cause maintenance headaches. Aside from the helper bot updating versions, it would be pretty easy to forget to update the reuse version in repo X. Then for N unique repos...

I think it could be a nice-to-have, but w.r.t. maintenance, the cons outweigh the pros for me.

[synackd]

I worry that will cause maintenance headaches.

How is it different than remembering to update the hard-coded version as you have it?

[seantrons]

I worry that will cause maintenance headaches.

How is it different than remembering to update the hard-coded version as you have it?

It would only be hardcoded in this repo as opposed to needing N repos to remember to update another value. Of course, either way N repos will need to keep the workflow ref up to date.

[synackd]

I worry that will cause maintenance headaches.

How is it different than remembering to update the hard-coded version as you have it?

It would only be hardcoded in this repo as opposed to needing N repos to remember to update another value. Of course, either way N repos will need to keep the workflow ref up to date.

Right, and it would still only be defined here as the default. Other repos could change it for temporary purposes, but the default version would have its source of truth here.

[synackd]

In other repos, you would just leave the default unless there was an issue with the version, in which case the input would allow temporary change.

[seantrons]

@synackd you drive a hard bargain, but I see your point. I'm still stuck at the office, but I'll get it implemented once I get back home.