Introduce support for Ruby #214
Conversation
Add content for building and publishing layers for Ruby based Lambda functions. See `ruby/README.md` for more detailed information.
* typo fix 'subdir' -> 'sub_dir' variable * include special packaging logic to support sourcing the agent from GitHub instead of RubyGems.org
- Conform to the AWS .zip file format - Use named keyword args for all handoffs between AWS -> wrapper script -> agent -> customer function
|
I'm ready to share a layer with a customer for beta testing! Thanks again, @mrickard! 
|
- Make `bin/setup` a bit more idempotent by having it call `bin/clean` first
- Rework the wrapper script
- Place everything except the 'handler' method in a class to avoid potential
customer method name collisions
- Always gaurantee the `AWS_LAMBDA_FUNCTION_NAME` env var is set, as its
presence will auto-enable serverless mode in the Ruby APM agent
- Rework the handler string (`'<path>.<method>'`) parsing logic to support
Ruby module and/or class namespaces while retaining support for bare
(toplevel) method names
- Introduce memoization of the parsed customer method namespace and method
name so that the parse only happens once and not once per invocation of the
customer handler method
- Activate the new memoization at `load` time, rather than at handler
invocation time so that the cache warming takes place when the wrapper
script is first loaded by AWS. This could possibly be helpful with
generating warnings regarding bad configuration earlier in the setup process
that the customer follows.
- Add a new Minitest test class to verify all of the different handler
string format possibilities
- Update the test function that gets wrapped during unit tests and the
corresponding `serverless.yml` config file to use a module and class
namespaced handler method
- Remove unused 'json' from the test function that gets wrapped during unit
testing
- Add additional source code comments
these changes aren't needed for building, but are needed for publishing
Optionally, the build and publish process can build a fresh extension via a local extension git clone's `make` process
|
We'll want to make sure the automation is wired up for this. For running automated tests on push/PR, we currently have GitHub Actions at https://github.com/newrelic/newrelic-lambda-layers/tree/master/.github/workflows ...though this could be made a little more responsive. For example, right now you're getting a lot of unreported status messages, because the changes aren't in the Node repo, and Node tests are skipped. (As they should be for that scenario...but here it presents as incomplete tests.) Currently the layer publishing jobs are defined in https://github.com/newrelic/newrelic-lambda-layers/tree/master/.circleci/config.yml ...which I'm currently porting to GHA. The build jobs may need a Dockerfile for Ruby. (If not, great! But Java and Node currently use them.) If so, those are defined in https://github.com/newrelic/newrelic-lambda-layers/tree/master/dockerfiles I don't expect you'd need to change the makefile, but you may want to take a look there. |
I'm curious about the approach Python takes, as I don't see Dockerfiles for the supported Python runtimes. For building the Ruby layers, I have made the build script fairly fault tolerant to a Ruby version that doesn't match the supported AWS Ruby Lambda runtime(s) (only Ruby v3.2 at this time), but it would be great to build things using the same Ruby version that we are targetting. If Docker helps with that, I welcome it. |
Added Dockerfile files for all supported Ruby runtimes (AWS only supports Ruby v3.2 at this time)
Ok, @mrickard. I've added a Ruby Dockerfile (only one because only one Lambda runtime exists) with |
Updates to support Ruby v3.3, while retaining support for Ruby v3.2
- updated `Makefile` - added GHA workflows
|
@fallwith This is looking good to me! This coming week I should be able to check in a fork, and we can verify built-layer behavior. |
move the GHA workflows
Tell pip3 how to operate for this context
Fixes for Ruby CI workflow
Better align with other languages
- reformat YAML - 3.2 and 3.3 are identical from what our CI and linter will give us
use the latest Ruby versions
GHA testing
Ruby GHA testing
use sed
outputs.value
use set-output to set the step's output
satisfy all outstanding RuboCop issues
silence the cop for the warning about unused named method args, as '_' renaming them will impact testing
Given that we perform both `docker run` and `docker build` on the same Dockerfile files, we need to have a `CMD` based operation instead of only having `RUN` ones.
Fix Ruby GHA
copy/paste typo fix
Dynamically adjust $LOAD_PATH prior to performing a `require` on New Relic Ruby gem(s) to account for the possibility of the instrumented Lambda function pointing to a gem path that does not match the path expected by the New Relic layer.
The Ruby gem path needs the tiny version of 0
Add content for building and publishing layers for Ruby based Lambda functions. See
ruby/README.mdfor more detailed information.