Closed elmar-hinz closed 1 year ago
Thanks @elmar-hinz I'm going to merge this. Seems to work as far as I'm concerned and further test it and work on migrating everything to the new setup.
Thanks for merging @DEADSEC-SECURITY . In the wiki I added a link to the future folder of the language manifest, while keeping the current one for the period of transition.
I tested the import and checked the imported skill is able to work as hitherto.
ok cool. Thanks @elmar-hinz
My Christmas present for home assistant
Solves: https://github.com/keatontaylor/alexa-actions/issues/132
The alexa devoloper console meanwhile provides an option, to directly import from github. This requires a certain project structure. See:
https://developer.amazon.com/en-US/docs/alexa/hosted-skills/alexa-hosted-skills-git-import.html#structure
What has been changed?
requirements.txt
has been moved to comply with thel the requirements of the importer.skill-package/
has been added for the same reason.About
skill-package/skill.json
I striped my personal
arn:aws:..
and tested, that the file will import without them. New uri will be automatically created during the import. I did also shrink the code as far as possible. The information is for a published skill and this skill is kept private anyway.About
skill-package/interactionModels/custom/en-US.json
I did only migrate the english version, to focus the pull requests to the necessary minimum. Also not to duplicate that much code. The translations are still available under
skill-manifests/
for classic deployment style as written in the wiki.Once it is proven that the import is working well, the other languages should be migrated, the
skill-manifests/
should be removed and the wiki should be adjusted.Testing the import
The developer console reads the master branch of the GitHub repository. I don't know if there is a way to feed in a different branch.
Either you create a second GitHub repo for to test with its own master branch. Or you have to apply the pull request directly to the master branch of the original repo. This is a little ugly. Either it pollutes the git history to revert it or you have to do it in
git push --force
style after fixing the history. This could confuse other developers. I don't think there are that many. though.