aws / aws-cli

Universal Command Line Interface for Amazon Web Services
Other
15.39k stars 4.09k forks source link

`CodeUri` defined in Globals section is ignored when packaging #3376

Open bmoller opened 6 years ago

bmoller commented 6 years ago

When executing aws cloudformation package to upload Lambda function ZIP's to S3, the CodeUri property is not inherited from the Globals section.

The SAM documentation makes it appear that it should be possible to specify CodeUri in the Globals section and have it inherited by all AWS::Serverless::Function resources. However, because the current package implementation does not do any kind of transformation involving the globals, this is ignored and the CodeUri property appears to lack a value. The behavior in this case is to zip up the current directory which can lead to all kinds of unexpected behavior (large archives described here, Lambda errors due to incorrect relative paths, etc.).

Would it be acceptable to add something like a dict.update() in the resource export function to make sure that global values for CodeUri are inherited? I can take a whack at it and submit a pull request.

bmoller commented 6 years ago

Okay, I wrote an implementation that combines the global and resource-level properties and it works as I expect in regards to archive creation.

The problem though is that this command also transforms the CodeUri property after it uploads the ZIP archive to S3. This means that as it iterates through the resources it would somehow have to track which are inheriting and which aren't, and finish by updating the global CodeUri property. I think this would make all of the functions in the artifact_exporter.py module a bit less agnostic.

It's looking like this would involve more than just a couple lines being added. I'm still happy to help, but I'm looking for maintainer guidance before I write a big patch that doesn't conform.

bmoller commented 6 years ago

Submitted pull request 3391 to deal with this behavior.

debora-ito commented 5 years ago

Hi @bmoller thank you for your contribution.

@sanathkr can you please review the PR?

elveskevtar commented 5 years ago

Hi, I would like to see this implemented. Took me a bit of time to realize this was the expected outcome of CodeUri being specified in Globals. Seems a little counter-intuitive.

marcelomd commented 5 years ago

Hi, What is the status on this? I fell for the CodeUri in globals today =\ Thanks

johnsonwj commented 4 years ago

In addition to the issues @bmoller listed in the original report, if there are multiple functions that share the same CodeUri, that directory is only packaged once if it is specified directly on each resource. If it is specified in Globals, the entire current directory is uploaded once for each function defined in the template which can make the build incredibly slow if the template has multiple functions that share the same source directory.

For a Node template, uploading the entire working directory will probably also include node_modules which is almost always not desirable.

alesculek commented 2 years ago

Hi,

I was facing the same issue today, I wanted to use CodeUri in the Globals since it does not make sense to repeat it in our project.

Unfortunately, I expected this to be working since it is mentioned in the docs here: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html

Could you please consider changing this to a bug?

Thanks.

GabrielHare commented 1 year ago

Up-vote for making this a bug.

Why I think this is a BUG:

Most developer-relevant services (e.g. Git) cache files in the root of a project, so the default package will include all of these (e.g. the entire Git history).

How I work around this issue presently: (1) All of my source code is in a subdirectory "source" (2) My IDE is configured to use that subdirectory as the source root (3) EVERY function in my template file declares "CodeURI: source/." (4) I check the package files after each update to make sure I didn't accidentally zip the whole project

Proposals: (1) Interpret Globals as if they were substituted in to the Resources declarations (2) Implement something like gitignore so that projects with standard structure won't package unnecessary artifacts