Split this into multiple repos for (1) a CDK Provider construct, (2) a CDK Role construct, (3) tools - CLI, (4) tools - lib

[douglasnaphas]

Split this into multiple repos

One per component. Maybe.

Considerations

Shared code

Where is there code shared between the components? Components that share common code, as opposed to one component being used within another, may want to live in the same repo.

Components

A CDK Provider construct

Usage: Clone the repo. cd into it, set AWS credential env vars, and run npm deploy, which will run cdk deploy. Deploy once per AWS account, but always from the same repo.

How about deploying withnpx? What if a package’s bin deployed an app?

A CDK Role construct

Usage: Put this in each repo that uses the GitHub Provider to authenticate from GitHub to AWS. This should arguably not even be a construct, because the best practice would be to have customized scoped-down permissions within each repo. That could be parameterized, though. This could be example code in a section like "How to use this repo."

Could be installed as a dependency, or copied from the README and adapted.

Tools - CLI

Usage: Run this from the CLI to see whether you have a GitHub OIDC provider in your account or not.

Maybe adapt so it's like "common providers," i.e., you could run like got-oidc-provider --github or got-oidc-provider --terraform, and have the CLI command exit 0 if there is one, non-zero otherwise.

Tools - lib/library Construct

Usage: Install this as a dep. If you have a GitHub OIDC Provider in your account already, return its ARN. If not, throw, with an instruction to create one using either this or another repo, depending on how the different pieces of AWS GitHub OIDC get split up.

Call the Construct like ExistingProvider.