Feature Request: Skill Events Endpoint Automated Deployment Support about ask-cli

[RonWang]

Hi @jsetton ,

So sorry for the late response! As you may find CLI's skill endpoint (infrastructure) support is domain-agnostic, but that's only for the endpoint under apis field in skill.json. The events endpoint should still be supported by CLI's connecting the source code to the Lambda deployment.

Thanks for your feature request it's totally valid and we will enhance our supports over your usage of notifications. Please stay tuned on this issue, we will let you know when we start, or understand more about your use case!

Thanks,
Ron

[kakhaUrigashvili]

@jsetton I will discuss this option with the team.

[jsetton]

@RonWang it has been a while since I opened this feature request. Since the ask-cli v2 has now been officially released, I am forced to require ask-cli v1 to be used on all my skill projects that uses skill events.

I was able to work around this limitation in v1 using the pre-deploy hook script to actually pre-deploy the Lambda function, using the aws-cli, in order to get the actual endpoint URI that would be added to the skill events manifest. In 2.x, there is no longer any options to do so since the build hook script runs after the skill is deployed.

[kakhaUrigashvili]

@jsetton I am looking into working on this feature. Just have few thoughts/questions:

1. Looks like you can set evens endpoint manually in skill.json. Is this not sufficient for your use case?
2. We could reserve EventsEndpoint output key from CloudFormation to configure events endpoint in skill.json. How can we do something similar for lambda deployer? Or may be we only support this feature for CloudFormation deployer?
3. Another option we could add new property in ask-resources that lets you indicate to reuse lambda arn from standard endpoint in the events endpoint. It would more standardized then option 2 but less flexible.

What are your thoughts?

[jsetton]

@kakhaUrigashvili Thanks for looking into this request.

Looks like you can set evens endpoint manually in skill.json. Is this not sufficient for your use case?

My original use case is when the skill events endpoint is the same as the standard endpoint. It cannot be set manually in advance since the latter value isn't known on initial deployment.

We could reserve EventsEndpoint output key from CloudFormation to configure events endpoint in skill.json. How can we do something similar for lambda deployer? Or may be we only support this feature for CloudFormation deployer?

The idea behind the output key was if a separate skill event Lambda function is deployed via the CloudFormation definition. The deployer would use the output value to update the skill manifest only if available. So, this use case can only be supported by cfn-deployer as it would be the user responsibility to configure that output key for the deployer to use.

Another option we could add new property in ask-resources that lets you indicate to reuse lambda arn from standard endpoint in the events endpoint. It would more standardized then option 2 but less flexible.

Why not default to the standard endpoint ARN when skill events are defined in the skill manifest and use the CloudFormation output key over that value if available? If you insist in having a property in ask-resources, you could have one that either indicates standard or cfn-output value for example.

[kakhaUrigashvili]

@jsetton Thank you for the reply. I will discuss the options with the team.

"Why not default to the standard endpoint ARN when skill events are defined in the skill manifest..." - mostly worry that it could be a breaking change.

[jsetton]

mostly worry that it could be a breaking change.

@kakhaUrigashvili How so? The defaulting should only come into play if the skill events endpoint wasn't manually configured in the manifest yet.

The logic I see is the following:

1. If skill events endpoint is configured in skill manifest and valid, no action needed.

2. If cfn-deployer and includes EventsEndpoint output key, use the key as endpoint ARN.

3. Otherwise, use standard endpoint ARN as fallback.

[kakhaUrigashvili]

@jsetton If existing Lambda is not configured to accept events payload, would it error? It probably would not break the skill, but would create errors in the logs. Lambda code would need to be update to handle events payload (ignore at minimum), right?

[kakhaUrigashvili]

@jsetton What would be the use case of separate 'EventsEndpoint'. You are not able to build/deploy multiple Lambda in the ask cli at the same time. Would only use case be: reuse lambda from standard endpoint (yes/no)?

[jsetton]

@kakhaUrigashvili

If existing Lambda is not configured to accept events payload, would it error? It probably would not break the skill, but would create errors in the logs. Lambda code would need to be update to handle events payload (ignore at minimum), right?

True but I would assume if skill events are configured in the skill manifest, either the relevant endpoint ARN would be included or the skill function would handle events payload. As you mentioned before, you could add a parameter in ask-resources.json to enable this feature.

What would be the use case of separate 'EventsEndpoint'. You are not able to build/deploy multiple Lambda in the ask cli at the same time. Would only use case be: reuse lambda from standard endpoint (yes/no)?

Good point. I was thinking that the Lambda function handling events payload could be built via the custom build script and then deployed by the CloudFormation stack. Anyway, this is not a use case I would need currently. So I have no objection to only support the reuse of the ARN from the standard endpoint.

[kakhaUrigashvili]

@jsetton Opened #47. Feel free to test/comment on the PR.

[kakhaUrigashvili]

added targetEndpoint in version 2.21.0

[jsetton]

@kakhaUrigashvili Sorry for my late reply. I finally got around to testing your change.

Unfortunately, I am not too sure how to use targetEndpoint and if it will resolve my use case. Maybe I should have given you a test scenario. As I initially mentioned in my request, I am trying to prevent the SMAPI error when the events endpoint isn't specified, the skill manifest is first deployed and subsequently that endpoint should be set to the standard one. Using version 2.21.0, I am still getting the same errors.

Here is my test scenario:

1. Create a new test project

$ ask new
Please follow the wizard to start your Alexa skill project ->
? Choose the programming language you will use to code your skill:  NodeJS
? Choose a method to host your skill's backend resources:  AWS Lambda
  Host your skill code on AWS Lambda (requires AWS account).
? Choose a template to start with:  Hello world
  Alexa's hello world skill to send the greetings to the world!
? Please type in your skill name:  skill-sample-nodejs-hello-world
? Please type in your folder name for the skill project (alphanumeric):  skill-sample-nodejs-hello-world

2. Add events configuration to skill manifest

$ vi skill-package/skill.json
[...]
    "events": {
      "endpoint": {},
      "subscriptions": [
        {
          "eventName": "SKILL_ENABLED"
        },
        {
          "eventName": "SKILL_DISABLED"
        }
      ]
    },
[...]

3. Deploy

$ ask deploy
Deploy configuration loaded from ask-resources.json
Deploy project for profile [default]

==================== Deploy Skill Metadata ====================
[Error]: {
  "skill": {
    "resources": [
      {
        "action": "CREATE",
        "errors": [
          {
            "message": "Object instance at property path \"$.manifest.events.endpoint\" has missing required property: \"uri\"."
          }
        ],
        "name": "Manifest",
        "status": "FAILED"
      }
    ]
  },
  "status": "FAILED"
}

[kakhaUrigashvili]

@jsetton I see what is the issue.
Since you have "events" property in skill-package/skill.json, the SMAPI validates to make sure endpoint is present. I don't think there is much we can do in the 'ask deploy' command - it is mostly server side validation issue.

One option I can see:

1. Remove "events" property in skill-package/skill.json and let ask deploy create "events" property.
2. Update events subscriptions with a smapi command.

newValue=$(jq '.manifest.events.subscriptions = [{"eventName": "SKILL_ENABLED"},{"eventName": "SKILL_DISABLED"}]' skill-package/skill.json)
printf "$newValue" > skill-package/skill.json
ask smapi update-skill-manifest -s $(jq -r '.profiles.default.skillId' .ask/ask-states.json) --manifest file:skill-package/skill.json

[jsetton]

@kakhaUrigashvili Thanks for providing your workaround. I now understand how the targetEndpoint option works.

Why not include an events object option in ask-resources.json that would populate the publications and subscriptions event names the same way you highlighted? It seems counterintuitive to give the options to set the target endpoint for events but force users to set the associated event names separately.

"events": {
  "publications": ["AMAZON.MessageAlert.Activated"],
  "subscriptions": ["SKILL_ENABLED", "SKILL_DISABLED"]
}

[jsetton]

@kakhaUrigashvili @RonWang Any update on this request?