aws / aws/aws-extensions-for-dotnet-cli

`--package` argument for package-ci

Open
#143 6 comments 0 reactions 0 assignees View on GitHub
feature-request module/cli-ext p3 queued
Dominant language
C#
Stars
393
Forks
90
Avg merge
2d 19m
Merged PRs (30d)
3

Description

## Describe the Feature

Currently, the only way to upload local code packages to S3 & transform the template is via `package-ci`. However, this may rebuild the artifact which may not be desired. Being able to upload local packages to S3 without rebuilding would add reliability to the build process.

An example workflow targeted by this change:
1. CodePipeline A compiles the artifacts for a complex project (50 stacks with parameters for each others' outputs), via `for x in */serverless.template; do (cd $(dirname ${x}) && dotnet lambda package --output-package out.zip); done;`
2. CodePipeline B deploys the artifacts to AWS account X, via `for x in */serverless.template; do (cd $(dirname ${x}) && dotnet lambda package-ci); done; stacker build environments/dev.yml stacker.yml`
3. CodePipeline C deploys the artifacts to AWS account Y, via `for x in */serverless.template; do (cd $(dirname ${x}) && dotnet lambda package-ci); done; stacker build environments/prod.yml stacker.yml`

### Is your Feature Request related to a problem?

When trying to deploy the same artifacts across multiple accounts, via a tool which manages dependencies between stacks (like stacker), code is likely to be recompiled rather than re-using the artifact. This can cause an issue if your deployment environment doesn't match your build environment, including e.g. access to private NuGet repositories

## Proposed Solution
Add `--package` parameter to `package-ci`, matching its behavior in `deploy-serverless` and `deploy-function`

### Describe alternatives you've considered
Making the S3 bucket readable by downstream accounts - this would allow a lower-security development environment to overwrite packages in use by the higher-security prod environment, rather than allowing prod to handle its own deployment/validation.

Another alternative would be to provide a separate action, which just does the template transformation but requires a pre-existing package.

### Environment
AWS CodeBuild, running in AWS CodePipeline

* [X] :wave: I may be able to implement this feature request
* [ ] :warning: This feature might incur a breaking change

It looks like all that's needed is to add the `Package` option [to PackageCICommand's DefaultLocationOption config](https://github.com/aws/aws-extensions-for-dotnet-cli/blob/master/src/Amazon.Lambda.Tools/Commands/PackageCICommand.cs#L122) to match [the implementation in DeployServerlessCommand](https://github.com/aws/aws-extensions-for-dotnet-cli/blob/master/src/Amazon.Lambda.Tools/Commands/DeployServerlessCommand.cs#L163)

---

This is a :rocket: Feature Request

Contributor guide

Open the contributing guide

Research direction

Start with src/Amazon.Lambda.Tools/Commands/PackageCICommand.cs, especially PackageCICommand's DefaultLocationOption config, and compare it with the implementation in src/Amazon.Lambda.Tools/Commands/DeployServerlessCommand.cs. Done means package-ci accepts the --package option, reuses the prebuilt local package, and still performs the required S3 upload and template transformation.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, csharp
Domain
cli, cloud
Issue type
Feature
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.