refactor(workflows)!: step 1, standardize workflow names and inputs

[seantronsen]

Description

Do let me know if this needs to be split into multiple PRs. My intention is to target a v4 release due to the number of breaking changes.

Note

I still need to do an interactive rebase to modify several commit names, shuffle the order around, and squash others for cleanliness.

Despite the upcoming VCS history changes, I recommend a rebase style merge unless this PR is split into multiple. The underlying changes are too diverse to reasonably crush into a single commit.

What this PR does:

• removes redundant name keys and dead run-name keys.
• migrates all applicable workflows to ubuntu-slim runners (workflows requiring the docker daemon are not eligible).
• removes deprecated actions
• removes unnecessary dependency installs
• merges unit testing with code coverage (one workflow to rule them all, avoids testing 2x)
• standardizes all key names to kebab case
• standardizes all workflow names to use the file basename (no extension)
• fixes several copyright formatting issues
• ensures sha pinning (release sha instead of tag name)
• bumps all versions to current release for all uses of third party actions
• renames several workflows.
  • internal workflows (to this repo) now prefixed with 0-local to simplify differentiation and sorting (ls order)
  • reusable workflows with multiple variants renamed to the format of <workflow>-<variant>.yml

Note

This is a first step toward taming

What this PR does not do:

• It does not refactor all the build workflows and split their steps into smaller, manageable, and reusable pieces.
  • I opted to save that task for later to reduce the burden on reviewers given this PR is large enough already.
• It barely touches build, release, or signing related components. all of those are subject to a redesign coming soon, so it didn't seem worth the effort to mutate them considering they're getting nuked in the near future.

The only listed issue this fixes is: #35

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.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[synackd]

Lot of good refactoring here.

One other thing I thought of is that ubuntu-slim imposes a hard 15-minute job limit and one CPU on every caller and so I'm wondering if it would be worth it to add a string runner input defaulting to the current default runners (ubuntu-latest/ubuntu-latest), and use runs-on: ${{ inputs.runner }} to change from the default. Just a thought.

[seantronsen]

One other thing I thought of is that ubuntu-slim imposes a hard 15-minute job limit and one CPU on every caller and so I'm wondering if it would be worth it to add a string runner input defaulting to the current default runners (ubuntu-latest/ubuntu-latest), and use runs-on: ${{ inputs.runner }} to change from the default. Just a thought.

Yeah... I noticed that in the docs and don't agree with the disparity (single cpu => 15 minutes, anything else => 6 hours), but rules are rules I suppose.

I'll make it parameterized as requested. Should I add any warnings? I've always been of the mindset that unit tests should only take a few minutes, while integration + e2e tests go for any sane number of hours.