git-repo-issues.md

General project management issue

The state of repository-playground git-based repo is that it "technically" mostly works:

• apart from the signing event triggering (see below), the core big ticket features are there
• The promised useful output is not there yet -- this applies to both signing event GitHub issue comments and the signer tool itself
• Lot of the planned security improvements not there either
• Unsure if there are gaps for sigstore-like use case
• expecting there to be a bunch of bugs

That said, it's getting harder to

• decide what to focus on next
• make good design decisions
• not introduce new bugs

I've filed ~20 issues. I think I would like to work through some of these with other folks periodically to decide what I should work on and what decisions to make... Another useful thing might be a high level review of the actual implementation to notice any serious design issues early on.

A couple of current high level issues are listed below.

Issue: Starting 0-N signing events from 1 workflow

This is issue 50. For background, a slide documenting the current workflows, actions and CLI commands: https://docs.google.com/presentation/d/12M5Nc1rGOOHrQ_45bFjvI7K78mk3h7digy1nO37kaBU/

Current design for version bumping offline signed roles is:

• Workflow version-bumps runs periodically (often), calls action offline-version-bump
• Action offline-version-bump goes through every offline role:
  • Runs playground-bump-expiring CLI command which looks at roles expires and x-playground-signing-period values and creates a new metadata version if needed
  • If a new metadata version was created, offline-version-bump action commits the changes to a new signing event branch

Normally pushing a branch would trigger signing-event workflow but from another workflow it does not.

Possible options:

• Just file an issue from offline-version-bump and require maintainer interaction (like adding a “sign” label or leaving a comment?)
• Use workflow_dispatch via GitHub API to trigger signing-event workflow, set the new branch as the ref.
• other alternatives?

Issue: How to test this monstrosity?

This is issue 31. I'd like to feel more confident about my refactoring and feature work.

I can (and should) add some tests for the individual python CLI commands, but the fact remains that real testing seems to require

• using real KMS keys and emulated HSM keys to
  • trigger actions by making commits to github.com
  • as well as to trigger actions directly or through cron
• testing from playground-templates downwards: e.g. if I now fork a new project, will it result into a working repository?
• and finally somehow monitoring that results are correct

No idea where to even start with this one...