On-push adhoc signing tasks

[ahal]

Braindumping an idea I had before I forget.

The current adhoc-signing mechanism is a bit clunky. CI generates dep signing tasks for every manifest in the signing-manifests directory. Then you need to manually trigger the signing request and fill in the manifest you desire. In my experience, we almost always want to do only a single signing request at a time.

I propose we:

1. Create a templates dir and a <name>.tmpl.yml file for each use case we want to support.
2. Create a generate-signing-manifest script which takes a template name and some other metadata (description, file size, etc) as input, and creates a valid manifest file at the repo root. Notably there will be only a single file, and re-running this script will clobber whatever was previously there.
3. Refactor the CI to run the signing task that corresponds to the manifest at the repo root and delete the Promote an Adhoc Signature action. This does move access control away from scopes and towards Github roles. Maybe this is a sticking point, but in practice only Releng has permission to the adhoc-signing repo anyway.

[ahal]

Interested in hearing any thoughts or concerns I may be missing.

[ahal]

One issue is that non-signing commits (e.g README changes) would generate signing tasks.. so maybe we'd need a flag in the commit message to be the trigger. Or we could only run them when the manifest file is modified.

[escapewindow]

We already have some cached tasks (fetch). It does sound like the biggest issue is running all the tasks all the time, and not the difficulty of promotion, so if we cache the dep-signing tasks, or only run them if the fetch task runs, we may be done without having to change the other parts.

As mentioned in channel we have other repos where we release-sign on push, so that's not the worst thing, but cached tasks or optimization may solve the main issue.

[escapewindow]

If we do the dep-signing caching, this is a dup of #16 .