Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let function package.individually config override service artifact #5364

Conversation

juanjoDiaz
Copy link
Contributor

What did you implement:

Closes juanjoDiaz/serverless-plugin-warmup#25

The problem that this feature solves is that, if you set a service level artifact, functions marked as package: individually: true are not packaged individually as you would expect but use the service artifact instead.

This change simply allows you do to do:

package:
  artifact: my-app.zip

function:
  ...
  myIndividualFunc:
    ...
    package: 
      individually: true

So all the functions will use the my-app.zip artifact but myIndividualFunc will be packaged normally

How did you implement it:

It's a pretty trivial change. Simply check if the function is set to package individually and, if so, package it individually. :)

How can we verify it:

I've added a test that proves that the feature works and doesn't break existing functionality.
It's pretty trivial to verify with a small app:

service: test

provider:
  name: aws
  runtime: nodejs8.10

package:
  artifact: my-app.zip # This can be an empty zip

functions:
  normalFunc:
    handler: func/handler.func
    events:
      - http:
          path: func
          method: post
  individualFunc:
    handler: func/handler.func
    events:
      - http:
          path: func2
          method: post
    package:
       individually: true

running serverless package with the above config will create a zip for func/handler.func (the func folder needs to exist of course).
At the moment is doesn't and it just tries to use my-app.zip instead

Todos:

  • Write tests
  • Write documentation (No docs change needed. this change just make it work as the current docs make it seems like it would work)
  • Fix linting errors
  • Make sure code coverage hasn't dropped
  • Provide verification config / commands / resources
  • Enable "Allow edits from maintainers" for this PR
  • Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

Copy link
Member

@horike37 horike37 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juanjoDiaz
Thank you for suggesting and implementing this solution 👍 I think this is a nice improvement.
Just reviewed and left one comment to the source code and. Check it please.

@@ -93,7 +93,8 @@ module.exports = {
}

// use the artifact in service config if provided
if (this.serverless.service.package.artifact) {
// and if the function is not set to be packaged individually
if (this.serverless.service.package.artifact && !funcPackageConfig.individually) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use lodash like _.isEmpty(funcPackageConfig.individually) for consistancy of other places.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that that is correct.
funcPackageConfig.individually is a boolean so _.isEmpty(...) will return true for all cases (true, false, undefined, null, etc.).
I searched the code base and couldn't find any example of using _.isEmpty in on boolean values.

Please correct me if I have misunderstood anything.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense 👍 I was not correct.
Thank you for the response and investigating about _.isEmpty 🥇

@horike37 horike37 added this to the 1.33.0 milestone Oct 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants