Jovo3 deploy after a long time away

deployment
#1

Well, I finally got my code switched over to using the AWS DynamoDB instance for its back end, at least locally. Yay!

(Biggest pitfall, for me: AWS configuration MUST be done BEFORE creating the DynamoDB client objects. With how I currently have the code organized, that gets a bit messy when both Jovo and my own code want to use Dynamo; I have it working but I need to clean it up.)

It’s running happily when I do jovo run and have Alexa talking to my own machine’s webhook.

HOWEVER:

… Unfortunately, it’s been a long time since I actually deployed code up to the lambda. In the past I used the jovo3 deploy --target zip approach, but that’s currently giving me an error message:

  > Bundle Project
    √ Copy source code to "./bundle"
    × Run "npm install --production"
      → [11:30:12] 'build-ts' errored after 7.46 s
      Zip "./bundle" folder
 »   Error: There was a problem:
 »   Error: Command failed: npm run bundle
 »   [11:30:12] 'compileTs' errored after 7.45 s
 »   [11:30:12] Error: Non-zero exit code of "2"
 »       at ChildProcess.<anonymous> (C:\Users\keshlam\jovo\new-sounds-on-demand\node
 »   _modules\gulp-run-command\index.es5.js:120:15)
 »       at ChildProcess.emit (node:events:520:28)
 »       at ChildProcess.emit (node:domain:537:15)
 »       at ChildProcess.cp.emit (C:\Users\keshlam\jovo\new-sounds-on-demand\node_mod
 »   ules\cross-spawn\lib\enoent.js:40:29)
 »       at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
 »       at Process.callbackTrampoline (node:internal/async_hooks:130:17)
 »   [11:30:12] 'build-ts' errored after 7.46 s

Theoretically my project.js file is configured to support lambda as one of the Stages (copy will follow), but as far as I can tell jovo3 deploy --stage lambda is not automatically uploading to the Lambda.

For what it’s worth, neither is leaving me with anything in the bundle directory.

I’m sure I’m missing something obvious again. Any ideas what?

Thanks in advance, as always. SO close to being able to ask Amazon to consider this for public release…!

/////////////////////////////////////////////////////////////////////////////////////////
// project.js

module.exports = {
    stages: {
	local: {
	    endpoint: '${JOVO_WEBHOOK_URL}'
	},
	lambda: {
  	    arn: 'arn:aws:lambda:us-east-1:046935287063:function:prod-new-sounds-on-demand',
 	    askProfile: 'admin', // if left out: "default" profile is used
	    endpoint: 'arn:aws:lambda:us-east-1:046935287063:function:prod-new-sounds-on-demand'
	}
    },
    alexaSkill: {
	nlu: 'alexa',
	manifest: {
	    apis: {
		custom: {
		    interfaces: [
			{
			    type: 'AUDIO_PLAYER',
			},
		    ],
		},
	    },
	},
    },
    googleAction: {
	nlu: 'dialogflow',
	projectId: `new-sounds-on-demand`,
    },
}
#2

Went back through my notes, and I had the no-zipfile problem before. The recommended workaround was to use npm run bundle. I’d forgotten that; fixed my convenience scripts to take that approach and I’m working on explictly getting the AWS CLI to upload the resulting zipfile… but meanwhile I can upload manually.

The other thing I need to do is give the lambda access to the DynamoDB tables. Should be able to find doc for that on the web.

Minor nuisance: Apparently the typescript compilation invoked by Jovo3 is using a different set of options than my configuration for tsc, so there are some new errors being reported – mostly it doesn’t like the fact that I tried to assign a type to the catch() variable. Not hard to reconcile, but… it might be good to document exactly what typescript options Jovo asserts, so we can catch these earlier in development.

#3

@keshlam to give your Lambda access to the Dynamo Db table got to IAM service in AWS. Select “Roles” and search for the name of your Lambda. When you have selected the Lambda’s role click the “add permissions” dropdown and select “attach policies”. Now in the search box type in Dynamo BD and the associated policies will appear. Select the check box for AWSDynamoDbFullAccess (you can restrict this later on) and click the button to atttch policy at the bottom. Go back to your lambda and check in the permissions tab. you lambda should now to access to Dynamo Db. If you dont see it, try refreshing

#4

The problem isn’t database access. It’s that the async code seems to be ending in the middle of a got.get() call (http fetch). Best guess I have right now is that something isn’t waiting in the lambda that does wait when running locally… So I’m going thru dropping in awaits to try to confirm/isolate that.