aws / aws/aws-extensions-for-dotnet-cli
`--package` argument for package-ci
- 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
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