pepperize / cdk-github Goto Github PK

Have for each construct at least a very simple test

For example matching a snapshot:

https://github.com/pepperize/cdk-github/blob/main/test/github-custom-resource.test.ts

describe("GithubCustomResource", () => {
  it("Should match snapshot", () => {
    // Given
    const stack = new Stack();
    new GithubCustomResource(stack, "CR", {
      // ...
    });
    
    // When
    const template = Template.fromStack(stack);
    
    // Then
    expect(template).toMatchSnapshot();
  });
});

Document the decision for rest over requests

There are two ways of using the GitHub REST API, the octokit.rest.* endpoint methods and octokit.request. Both act the same way, the octokit.rest.* methods are just added for convenience, they use octokit.request internally.

https://github.com/octokit/octokit.js#rest-api

With https://github.com/octokit/plugin-rest-endpoint-methods.js/ one can send all the request parameters as a single object, no matter if it's a route, query or body parameter

There are already Custom Resources in the public CloudFormation Registry cloudformation-github-resource-providers and cdk-cloudformation.

My understanding is they are complementary to our library. They are really good for regular use cases and can be used complementary with this custom construct.

This more flexible custom construct fills then the gap what is not implemented and also the ability to use a Github app or unauthenticated instead a PAT.

We may skip on higher constructs and refer to such libraries. Additional we can give some quickstart hint and an example for interop.

thx Konstantin

While using the list method the handler should use the paginator https://github.com/octokit/rest.js/

Use type hinting from @types/aws-lambda in the handler

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/trigger/cdk-custom-resource.d.ts

To merge with https://github.com/WtfJoke/cdk-github we need to support the feature to https://docs.github.com/en/rest/actions/secrets#create-or-update-a-repository-secret

See:

https://github.com/WtfJoke/cdk-github/blob/a30cc750581010e769c390b320158c92e705ada2/src/handler/secrets/github-secret-encryptor.ts#L1-L23

A possible solution could be wrapping the SecretsManager Secrets or the SSM ParameterStore StringParameter by a class and using a symbol/identifier that can be used on JSON.parse in the lambda handler like PhysicalResourceIdReference

When I provide a custom PhysicalResourceId in the onCreate GithubApiCall, then maybe I want to reference it in the onUpdate GithubApiCall.

See https://github.com/pepperize/cdk-github/blob/main/API.md#physicalresourceidoptional-

This mimics the very same behavior of AWS CDK - custom_resources -PhysicalResourceIdReference

• Explain how to retrieve response values https://github.com/pepperize/cdk-github/blob/main/API.md#@pepperize/cdk-github.GithubCustomResource.getAtt
• Add some more examples like setting up members, teams, ...
• Links to API Reference https://github.com/pepperize/cdk-github/blob/main/API.md from Readme
• Add a better usage section to README

The current implementation offers the ability to fully configure the GitHub AuthStrategies either by SecretsManager or SSM ParameterStore for GitHub App (with installationId), a PAT or unauthenticated

https://github.com/octokit/authentication-strategies.js/#authentication-strategiesjs

See also https://github.com/pepperize/cdk-github/blob/main/API.md#static-functions--1

Do we have to support additional AuthStrategies. Or by different AWS Service i.e. AuthOptions.tokenAuthFromSecret(secret: ISecret), AuthOptions.tokenAuthFromParameter(parameter: IParameter)