Feature Request: Skill Metadata Profile Based Parameters Support

[jsetton]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request 
[ ] Other... Please describe: 

Expected Behavior

In order to use different skill metadata properties based on the profile used, it would be nice to have the ability to set/override some of these properties when specified in ask-resources.json. This would be helpful, for example, when using separate development and production profiles to differentiate publishing information.

{
  "profiles": {
    "development": {
      "skillMetadata": {
        "src": "./skill-package",
        "publishingInformation": {
          "isAvailableWorldwide": false,
          "distributionMode": "PRIVATE",
          "testingInstructions": "No test instructions"
        }
      },
      ...
    },
    "production": {
      "skillMetadata": {
        "src": "./skill-package",
        "publishingInformation": {
          "isAvailableWorldwide": true,
          "distributionMode": "PUBLIC",
          "testingInstructions": "Specific test instructions"
        }
      },
      ...
    }
  }
}

[kakhaUrigashvili]

@jsetton You can specify different skill package folder for different profile to accomplish this. I see what you are asking about ability to overwrite and merge skill manifest properties. I can talk to the team about it, but it definitely will be a big change. I think many things like that could be accomplished if configurations for ask cli would be template language driven similar to Helm for Kubernetes. Without using some template language, we would be just constantly adding different flags and overwrites in config file, since currently it is not generic enough.

[jsetton]

You can specify different skill package folder for different profile to accomplish this. I see what you are asking about ability to overwrite and merge skill manifest properties.

@kakhaUrigashvili What about having the ability to specify the skill manifest file name or perhaps use the profile name skill-<profileName>.json automatically, falling back to skill.json if former not present? Using a separate folder may be overkill if the same customized files are used between the two profiles.

{
  "profiles": {
    "development": {
      "skillMetadata": {
        "src": "./skill-package",
        "manifest": "skill-developement.json"
      },
      ...
    },
    "production": {
      "skillMetadata": {
        "src": "./skill-package",
        "manifest": "skill-production.json"
      },
      ...
    }
  }
}

[kakhaUrigashvili]

@jsetton I like the idea of specifying a skill manifest file. Let me talk to the team about it tomorrow.

[kakhaUrigashvili]

@jsetton I did some testing and we would not able have custom name for manifest file. Skill package format is expecting it to be always called skill.json https://developer.amazon.com/en-US/docs/alexa/smapi/skill-package-api-reference.html

When I try to provide custom name, I get the following error from the API.

"Invalid package. 'skill.json' must be present in the package."

There is probably a way to do some manipulation by renaming file right before the upload, but I am not sure if we want to go that route.

[RonWang]

Hey @jsetton

Thanks for your great feature request! My understanding of your intention here is to have skill metadata JSONs stage controlled, since from your example the CLI profiles (development/production) represent your skill stages. Do you usually develop in the "development" profile, and merge to that "production" profile only to go to certification and make it live?

For this idea of stage(profile)-controlled skill manifest, I wondered what's the value to you for using this? The properties inside publishingInformation will only be consumed, when skill passes certification and goes live (e.g. the usage of distributionMode ), since what the skill project represents is not cert/live stage, why not use the same settings between development and production profile?

Thanks, Ron

[jsetton]

@RonWang

Do you usually develop in the "development" profile, and merge to that "production" profile only to go to certification and make it live?

Correct. The "production" profile is basically the customer interacting environment including beta testing. Having two separate profiles prevents some of the production resources from being updated by mistake.

The properties inside publishingInformation will only be consumed, when skill passes certification and goes live (e.g. the usage of distributionMode ), since what the skill project represents is not cert/live stage, why not use the same settings between development and production profile?

As mentioned above, I am trying to safeguard the production environment. The fact that I am using different profiles, having different publishingInformation would prevent the non-production profile from going through the skill certification by mistake, especially when using the ASK CLI to do so. Also, setting distributionMode to PRIVATE makes the specific skill show under the "Private Skills" tab in "Your Skills" Alexa user console, which makes it easier to identify the development skill from the live one.