PS C:\work> jets new demo Traceback (most recent call last): 5: from C:/Ruby25-x64/bin/jets:23:in `<main>' 4: from C:/Ruby25-x64/bin/jets:23:in `load' 3: from C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/jets-1.9.25/exe/jets:4:in `<top (required)>' 2: from C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/jets-1.9.25/exe/jets:4:in `each' 1: from C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/jets-1.9.25/exe/jets:5:in `block in <top (required)>' C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/jets-1.9.25/exe/jets:5:in `trap': unsupported signal SIGQUIT (ArgumentError)
To reference shared resource ARNs, jets usually grab the ARN from the CloudFormation shared stack output when the lambda function runs. Example from docs: https://rubyonjets.com/docs/shared-resources
topic_arn = Alert.lookup(:delivery_completed) # looks up output from the Alert
The lookup method is essentially “lazy”. It references the Shared Resource after it’s been created.
Thinking the current recommendation is to use the lookup method and lookup the ElasticSearch ARN and then domain in the app code.
If you like it available everywhere as a global ENV var. Maybe try looking it up and setting as an ENV var in an initializer. Haven't tried this yet but in theory it should work.
It’s kind-of a chicken and egg problem. The lambda env variables are set as part of the
jets deploy build process. So the CloudFormation output is not yet available until at least the 2nd deploy, after the shared resource has been created. So think it is probably easier to reason about the code if it's looked up lazily.
ElasticsearchServiceshared resource I created definitely spins up and works, but I can't use
ElasticsearchService.lookup(:domain_endpoint)to retrieve the endpoint. I can't even lookup
:arn. Do you have any recommendations for debugging this? I've tried running the console in the environment I've deployed to and I just get
nilfor those values.
FYI for those interested. Released jets v2. Made several improvements:
Here's the routing guide: https://rubyonjets.com/docs/routing/guide/
contextargument, rubocop complains I'm not using it. I can't see me ever using the context argument either... has anyone come up with a solution for not using the context argument and having rubocop not complain about it? I can add in an ignore comment, or disable the rule for my function, but it feels a bit messy.
No ETA. Will be traveling more soon, including speaking at the Southeast conference to speak on Jets https://southeastruby.com/ 🎉 There’s also work 😄
So will be a while. Hopefully someone chips in. Interested to see what you come up with. 👍
Think eventually these 2 approaches to auth would be good.
Making both key-turn would be great. Think both are a decent amount of work.
RE: rubocop context warning