Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

localPublish plugin should prefer user-provided runtime #2450

Closed
benbrown opened this issue Mar 31, 2020 · 2 comments
Closed

localPublish plugin should prefer user-provided runtime #2450

benbrown opened this issue Mar 31, 2020 · 2 comments
Assignees
Labels
R9 Release 9 - May 15th, 2020

Comments

@benbrown
Copy link
Contributor

benbrown commented Mar 31, 2020

Is your feature request related to a problem? Please describe.

The current localPublish plugin manages an "internal" copy of the bot project for testing purposes - it copies the declarative assets into a folder, and provides a copy of the runtime code.

This makes it hard and very confusing to make customizations to the runtime code or schema, as these files do not exist in the expected location.

If a user has customized or otherwise created a bot project on their own, Composer should attempt to use this copy of the code rather than providing its own.

Describe the solution you'd like

Update the localPublish plugin so it will use an existing bot project on disk if a copy of the runtime code is present. That is, it will run the project out of the user specified folder rather than copy it to an internal location.

See #2470 for info on how the custom runtime setting is controlled.

  1. When localPublish.publish is called on a bot project, it will FIRST check the bot's settings for the custom runtime settings.
  2. If custom runtime is not enabled, continue with current functionality of creating a "temporary" version of the project to run
  3. If custom runtime is enabled, use the user-specified start command in the user-specified folder
@benbrown benbrown added Type: Enhancement Needs-triage A new issue that require triage labels Mar 31, 2020
@cwhitten cwhitten removed the Needs-triage A new issue that require triage label Mar 31, 2020
@cwhitten cwhitten added the R9 Release 9 - May 15th, 2020 label Apr 2, 2020
@benbrown
Copy link
Contributor Author

this is in progress!

@boydc2014 boydc2014 removed their assignment Apr 18, 2020
@cwhitten
Copy link
Member

#2572 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R9 Release 9 - May 15th, 2020
Projects
None yet
Development

No branches or pull requests

5 participants