feat: azure publish plugin

[benbrown]

Description

Task Item

close #2461
close #2757

Screenshots

[benbrown]

@VanyLaw We need to simplify this in a few ways.

do not provision in the plugin

The provisioning part (botProjectDeploy.create) should not be part of the Composer publish action. This should happen outside of the plugin, via a command line tool. We need to figure out how to make this an easy to use script -- possibly bundle it with the ejected code.

Ideally, we would be able to do something like this:

provisionComposer --name <bot> --location westus --environment dev --appPassword <password> --luisAuthoringKey --<key> --token <token> --subscription <subid>

This would perform the provision, and after completion, output a configuration profile, like:

Your Azure hosting environment has been created! Copy paste the following configuration into a new profile in Composer's Publishing tab.

{
accessToken: <token>,
subscription: <subid>,
environment: <environment>,
luisAuthoringKey: <key>,
luisAuthoringRegion: <region>,
... other settings possibly including all provisioned services...
}

make sure the plugin does not expect the declarative assets to be local

Right now, the plugin is doing a simple recursive copy of the files from the bot project's source folder. However, this will not work for all storage providers.

Instead, you should use the project.files array to access the file content and write them to the appropriate location.

Consider alternative mechanisms for building/deploying

Right now, the plugin copies the declarative assets from the bot project along with the c sharp code project from the template into a single TEMP folder. Inside this temp folder, it updates an appsettings.deployment.settings file after provisioning, and then uses that for the deploy.

There are a number of flaws in this approach, though a big one is that this requires provisioning to occur immediately before deploying and will only work for one project at a time, and only work once since provisioning status is held in the plugin's memory and not serialized anywhere.

• where should information about the provisioned resources live? For maximum flexibility, this should probably live in the publishing profile - this would allow Composer to write the appropriate appsettings.json file during deploy. (Is this correct?)
• How will this work with an ejected runtime? Is it as easy as just copying the source code from a different path? (I think so)
• When using an ejected runtime, should the build occur in a temp folder or should it occur in the normal project folder? (not sure!)

Error handling during provisioning

Right now, a lot of the errors just return and cause no error to be raised. These critical errors should probably throw an error and cause the promise to reject so that they can be handled properly.

[VanyLaw]

@benbrown Can't agree more. I did some update today.

1. To handle the token expire more user-friendly, I split the login into a js script which return a credential. user can simpliy run this before start composer. And no need to update the profile even the token expired. The credential will be read before composer start and refresh in memory.
2. Instead of the a single TEMP folder, I used the hask key of profile config(name, location,env,````) as a folder name to save those declarative assets and runtime. and add the field create to defined provision or not. If user use the same config to publish different bots, it will only replace the composerDialogs folder in it and use the same config and appsettings.Deployment.json to publish.

I will keep doing the rest and move the provision out of the plugin next.

[github-actions]

Coverage remained the same at 0.0% when pulling a6e0f45 on wenyluo/azure into 3a7dbce on master.