Add Ruby to Supported Runtime Enum #866

awood45 · 2018-12-18T00:05:03Z

This is required for the Ruby support added to aws-lambda-builders to work in SAM CLI.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

awood45 · 2018-12-18T00:30:35Z

I'll say that, right now, the example function is breaking when packaged and deployed. I'm investigating why this is.

sriram-mv · 2018-12-18T04:58:07Z

samcli/lib/build/app_builder.py

@@ -57,6 +57,12 @@ def _get_workflow_config(runtime):
            dependency_manager="npm",
            application_framework=None,
            manifest_name="package.json")
+    elif runtime.startswith("ruby"):


Woot! sam build for ruby! :)

sriram-mv · 2018-12-18T04:59:38Z

...local/init/templates/cookiecutter-aws-sam-hello-ruby/{{cookiecutter.project_name}}/README.md


 ```bash
 sam package \
-    --template-file template.yaml \
+    --template-file .aws-sam/build/template.yaml \


Need to investigate this, thought there was some code that automatically picked this up.

No need to add --template-file when using build anymore. We will auto pick up build if it exists otherwise default to template.yaml.

https://github.com/awslabs/aws-sam-cli/blob/develop/samcli/commands/package/__init__.py#L21
and
https://github.com/awslabs/aws-sam-cli/blob/develop/samcli/commands/_utils/options.py#L35

sriram-mv · 2018-12-19T19:47:15Z

This looks good, @awood45 do you want to add an integration test for sam build with ruby as well? and we can merge this.

sriram-mv · 2018-12-20T01:12:13Z

The integ tests worked locally, need to get a new release of the builders out to get the new docker images.

jfuss · 2018-12-20T17:58:47Z

...local/init/templates/cookiecutter-aws-sam-hello-ruby/{{cookiecutter.project_name}}/README.md

-rvm install ruby-2.5.0
-rvm use ruby-2.5.0
-rvm --default use 2.5.0
+rvm install ruby-2.5.3


Does patch version need to be specified here?

It's a best practice, yes. Ruby on AWS Lambda uses version 2.5.3 - while 2.5.0 will technically work for builds, there are security patches present on 2.5.3 that are not present on 2.5.0, so I would not intentionally direct users to use an older version in this case.

Is there a way the newest just gets installed. I am worried this will be out of date and something we need to maintain.

do we need to provide instructions on how to use install Ruby for Ruby developers? I wonder if Requirements (ruby 2.5) suffices as we do with Python and Node init

This is how you install Ruby. Not sure what the question is @heitorlessa

Sure, let me try once more and let me know if it's clearer:

Do we need to tell Ruby developers how they should install Ruby?

Customers trying Ruby quickstart should have Ruby installed, shouldn't we assume that and cut the Installation part?

I wouldn't add install instructions. People who use languages like ruby, go etc will have their tooling in place.

It would be like every pkg internally saying start off by installing the Amazon builder tools.

jfuss · 2018-12-20T18:02:37Z

...local/init/templates/cookiecutter-aws-sam-hello-ruby/{{cookiecutter.project_name}}/README.md

@@ -7,7 +7,8 @@ This is a sample template for {{ cookiecutter.project_name }} - Below is a brief
 ├── README.md                   <-- This instructions file
 ├── hello_world                 <-- Source code for a lambda function
 │   ├── app.rb                  <-- Lambda function code
-├── Gemfile                     <-- Ruby dependencies
+│   ├── Gemfile                 <-- Ruby function dependencies
+├── Gemfile                     <-- Ruby test/documentation dependencies


Not a huge fan of the Double Gemfile. How do I know or remember which one to update? Is this absolutely needed? For Node, we had tests under the function directory and excluded them through .npmignore

So...I'm open to ways we can support this through sam build. If we had to pick one, we would not include the global test/docs Gemfile, but then the way the example code does testing wouldn't work easily. I don't know how to get SAM CLI to use a Gemfile in the root directory to build vendored dependencies into each function directory in a single command.

It's actually very possible that multiple Gemfiles may be a reality, and that we just need to teach the paradigm. Why?

Layers will eventually be a part of this build story, and you only want to specify those dependencies within the layer itself. In fact, we may want builds where we say "don't fetch all dependencies I need, expect some to be resolved in a layer" down the road.

I may not want all of my dependencies in every function.

I may want global dependencies in my build structure.

There is actually precedent for this, the Ruby SDK repo itself: https://github.com/aws/aws-sdk-ruby/

We have a global Gemfile for testing, building, and documentation generation. Within each modular package, we have its own gemspec for only the required dependencies. This may be the correct pattern for modular Lambda functions.

I can image an appropriate alternative approach, perhaps where we use "groups" per function to keep dependency versions in sync in a global Gemfile. In an ideal world, we could provide options to the user.

jfuss · 2018-12-20T18:18:32Z

tests/functional/local/apigw/test_local_apigw_service.py

@@ -630,7 +630,7 @@ def make_service(list_of_routes, function_provider, cwd):

 def make_service_response(port, method, scheme, resourcePath, resolvedResourcePath, pathParameters=None,
                          body=None, headers=None, queryParams=None, isBase64Encoded=False):
-    response_str = '{"httpMethod": "GET", "body": null, "resource": "/something/{event}", "requestContext": {"resourceId": "123456", "apiId": "1234567890", "resourcePath": "/something/{event}", "httpMethod": "GET", "requestId": "c6af9ac6-7b61-11e6-9a41-93e8deadbeef", "accountId": "123456789012", "stage": "prod", "identity": {"apiKey": null, "userArn": null, "cognitoAuthenticationType": null, "caller": null, "userAgent": "Custom User Agent String", "user": null, "cognitoIdentityPoolId": null, "cognitoAuthenticationProvider": null, "sourceIp": "127.0.0.1", "accountId": null}, "extendedRequestId": null, "path": "/something/{event}"}, "queryStringParameters": null, "headers": {"Host": "0.0.0.0:33651", "User-Agent": "python-requests/2.20.0", "Accept-Encoding": "gzip, deflate", "Accept": "*/*", "Connection": "keep-alive"}, "pathParameters": {"event": "event1"}, "stageVariables": null, "path": "/something/event1", "isBase64Encoded": false}' # NOQA
+    response_str = '{"httpMethod": "GET", "body": null, "resource": "/something/{event}", "requestContext": {"resourceId": "123456", "apiId": "1234567890", "resourcePath": "/something/{event}", "httpMethod": "GET", "requestId": "c6af9ac6-7b61-11e6-9a41-93e8deadbeef", "accountId": "123456789012", "stage": "prod", "identity": {"apiKey": null, "userArn": null, "cognitoAuthenticationType": null, "caller": null, "userAgent": "Custom User Agent String", "user": null, "cognitoIdentityPoolId": null, "cognitoAuthenticationProvider": null, "sourceIp": "127.0.0.1", "accountId": null}, "extendedRequestId": null, "path": "/something/{event}"}, "queryStringParameters": null, "headers": {"Host": "0.0.0.0:33651", "User-Agent": "python-requests/2.20.1", "Accept-Encoding": "gzip, deflate", "Accept": "*/*", "Connection": "keep-alive"}, "pathParameters": {"event": "event1"}, "stageVariables": null, "path": "/something/event1", "isBase64Encoded": false}' # NOQA


grrr.. let's just pin requests. We have installers now, so pinning isn't as dangerous. If customers run into conflicts, this gives them a reason to get onto our installers and out of pip (which is what we want/recommend anyways)

We could remove requests from test requirements (dev.txt) , and pin the requests in the base.txt.

But if we pin, we would periodically need to bump up requests as when there is a release of requests.

WIP: Unit tests may have a notion of a central Gemfile that isn't compatible with per-function Gemfile pattern that `sam build` expects.

Global Gemfile for tests. Gemfile in the function for use in tests. Hat tip to lauratpa and her PR aws#860 which is the core of this part of the change set.

awood45 mentioned this pull request Dec 18, 2018

Update hello world ruby template #860

Closed

6 tasks

sriram-mv reviewed Dec 18, 2018

View reviewed changes

jfuss requested changes Dec 20, 2018

View reviewed changes

awood45 and others added 7 commits December 20, 2018 14:06

Add Ruby to Supported Runtime Enum

dfbd903

Ruby Project Template Changes

b2cdfde

WIP: Unit tests may have a notion of a central Gemfile that isn't compatible with per-function Gemfile pattern that `sam build` expects.

Tweaks

ac35ac2

Global Gemfile for tests. Gemfile in the function for use in tests. Hat tip to lauratpa and her PR aws#860 which is the core of this part of the change set.

Ruby Init App in Working State

ee51bb4

fix: add integration tests for sam build - ruby

f8988c3

bump: version bump aws-lambda-builders to 0.0.5

b79f2fd

fix: requests version pin and imports

381a7c5

sriram-mv force-pushed the ruby-support branch from 402f234 to 381a7c5 Compare December 20, 2018 22:12

fix: string paths on Pathlib for py2

98cf7b0

heitorlessa mentioned this pull request Dec 21, 2018

Simplify built-in quickstarts to a simple hello world #849

Merged

18 tasks

fix: README - add references to build

24a3aed

jfuss approved these changes Dec 21, 2018

View reviewed changes

sriram-mv merged commit 8f4b180 into aws:develop Dec 21, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Ruby to Supported Runtime Enum #866

Add Ruby to Supported Runtime Enum #866

awood45 commented Dec 18, 2018

awood45 commented Dec 18, 2018

sriram-mv Dec 18, 2018

sriram-mv Dec 18, 2018

jfuss Dec 19, 2018

sriram-mv commented Dec 19, 2018

sriram-mv commented Dec 20, 2018

jfuss Dec 20, 2018

awood45 Dec 20, 2018

jfuss Dec 20, 2018

heitorlessa Dec 21, 2018

jfuss Dec 21, 2018

heitorlessa Dec 21, 2018

sthulb Dec 21, 2018

jfuss Dec 20, 2018

awood45 Dec 20, 2018

awood45 Dec 20, 2018

jfuss Dec 20, 2018

sriram-mv Dec 20, 2018

Add Ruby to Supported Runtime Enum #866

Add Ruby to Supported Runtime Enum #866

Conversation

awood45 commented Dec 18, 2018

awood45 commented Dec 18, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sriram-mv commented Dec 19, 2018

sriram-mv commented Dec 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment