fix: Remove build golang lambda

[wchaws]

Fixes #222

• Documentation
• Remove skopeo and enable crane
• Remove golang build
• Include crane binary in release. Follow https://github.com/cdklabs/awscdk-asset-kubectl/tree/kubectl-v29/main
• Python unit test
• Test cases

Test Cases

Test project can be found at https://github.com/cdklabs/cdk-ecr-deployment/blob/dev/test/example.ecr-deployment.ts.
Instructions can be found at https://github.com/cdklabs/cdk-ecr-deployment/tree/dev?tab=readme-ov-file#sample-testexampleecr-deploymentts

1. Copy from local cdk docker image asset to ECR repo.

Prerequisite:

1. An existing ECR repo.

const image = new DockerImageAsset(this, 'CDKDockerImage', {
  directory: path.join(__dirname, 'docker'),
});

new ecrdeploy.ECRDeployment(this, 'DeployDockerImage1', {
  src: new ecrdeploy.DockerImageName(image.imageUri),
  dest: new ecrdeploy.DockerImageName(`${cdk.Aws.ACCOUNT_ID}.dkr.ecr.us-west-2.amazonaws.com/my-nginx:latest`),
});

2. Copy from a ECR repo to another ECR repo.

Prerequisite:

1. Two existing ECR repo.

new ecrdeploy.ECRDeployment(this, 'DeployDockerImage1', {
  src: new ecrdeploy.DockerImageName(`${cdk.Aws.ACCOUNT_ID}.dkr.ecr.us-west-2.amazonaws.com/AAAAlatest`),
  dest: new ecrdeploy.DockerImageName(`${cdk.Aws.ACCOUNT_ID}.dkr.ecr.us-west-2.amazonaws.com/BBBB:latest`),
});

3. Copy from docker registry to ECR repo.

new ecrdeploy.ECRDeployment(this, 'DeployDockerImage2', {
  src: new ecrdeploy.DockerImageName('nginx:latest'),
  dest: new ecrdeploy.DockerImageName(`${cdk.Aws.ACCOUNT_ID}.dkr.ecr.us-west-2.amazonaws.com/my-nginx2:latest`),
});

4. Copy from private docker registry to ECR repo.

Prerequisite:

1. An existing ECR repo.
2. A private docker registry and an access token for the registry.
3. Create a AWS Secrets Manager secret to store the access token. The format must be <username>:<password>.

Notice: The creds parameter can be the secret name or arn of the aws secrets manager in the same cdk stack region.

// Copy from private docker registry to ECR.
// The format of secret in aws secrets manager must be plain text! e.g. <username>:<password>
new ecrdeploy.ECRDeployment(this, 'DeployDockerImage3', {
  src: new ecrdeploy.DockerImageName('your-private-docker-registry/nginx:latest', 'username:password'),
  // src: new ecrdeploy.DockerImageName('your-private-docker-registry/nginx:latest', 'aws-secrets-manager-secret-name'),
  // src: new ecrdeploy.DockerImageName('your-private-docker-registry/nginx:latest', 'arn:aws:secretsmanager:us-west-2:000000000000:secret:id'),
  dest: new ecrdeploy.DockerImageName(`${cdk.Aws.ACCOUNT_ID}.dkr.ecr.us-west-2.amazonaws.com/my-nginx3:latest`),
}).addToPrincipalPolicy(new iam.PolicyStatement({
  effect: iam.Effect.ALLOW,
  actions: [
    'secretsmanager:GetSecretValue',
  ],
  resources: ['*'],
}));

5. Regional test

Select some regions to test if it's able to work

[xazhao]

Starting to look into this PR. Because I'm not familiar with this L2, could you please add some details to help me understand the change?

• Reason of changes
• What are changes

I see Python is added and Go is removed. Is there a reason for that? And are you removing all Go code from the repo?

[xazhao]

Does this script run on customer's machine?

[xazhao]

Correct me if I'm wrong: this shell script will run whenever customers run synth().

Instead of downloading it every time when customers use the construct, can we do this part in our release process and publish the layer.zip. So they don't need to connect to Github which has availability risk.

[rix0rrr]

This PR is doing too much.

It's changing how the asset is built, as well as replacing the code inside the asset and changing functionality.

Those might all be valid changes, but I'd feel a lot better if they were submitted separately in different PRs.

[rix0rrr]

This section needs some clarification that these instructions only apply if you're developing on the repository, not if you're a user of the construct.

README.md is typically consumer-targeted, and the section title says "Sample", so it should (mostly) only contain instructions for consumers.

These instructions would make more sense in CONTRIBUTING.md in a section title "How to run tests".

If you want to keep them here, clearly label the instructions as intended for developers, not for consumers.

[rix0rrr]

What does this mean?

[rix0rrr]

I really like making 2 distinct changes in a single PR here.

The problem was: the Lambda code is downloaded at synth time.

The expected solution was: the Lambda code is built at release time and bundled into the NPM package.

You are doing that, and also replacing the code in the Lambda layer with a downloaded binary and a Python wrapper at the same time.

This seems to me like it doesn't appreciably simplify the solution to the immediate problem, as well as introduces another layer of risk that I'd rather avoid. The proposed layer code change should be submitted as a separate PR.

[rix0rrr]

This behavior can/should probably be triggered more intelligently. For example, by examining whether or not a tag is supplied, or adding a triggerEveryDeployment?: boolean/mutableSourceUri?: boolean property.

And in any case, functionality changes should not be part of the PR whose sole purpose it is to make the package behave more reliably.

[rix0rrr]

For maximum user impact, it would be better to leave this parameter in place, and to not bump the Major Version. That way, all users currently using the affected version can transparently upgrade to a fixed version. Ignore the property if supplied and report a warning.

Then, in a future Major Version you can remove this parameter, to have a correct API contract.