Bug 430237

Comment 1 Mike Wilson 2014-03-13 09:55:43 EDT

For the behaviour of the "Deploy" button, I am relatively confident that what most people would expect is for us to use the same org and space as was used the last time we deployed, plus the contents of the currently found manifest file. (Obviously, if it has not been set already, you would need to prompt the first time.)

These are the pieces of information that we currently require to deploy:
1) target
2) user (and password for sites other than bluemix)
3) organization
4) space
5) a bunch of other "stuff" from the manifest file.

Since we are (today) using the manifest to hold much of the stuff that the user specifies for how to get the app running, it feels like we should be consulting that every time we deploy. This is *not* the same as saying that we are starting from scratch since, for example, we are careful to not recreate existing services for those using v5-style manifests.

Note that we should also put in support for climbing *up* the directory tree from whatever is currently selected to find the manifest, and we should display the path of the manifest file that is being used for the deployment in the info message.

Each time one of the above pieces of information changes, a new record of that deployment should be made (i.e. this is our deployment configuration list). This list should be sorted in MRU-first order and have operations to remove individual items. 

Having a separate gui to modify the entries in the deployment configuration list and/or add new ones would also be desirable.

Comment 2 Mike Wilson 2014-03-13 09:58:09 EDT

Note that if we had a gui for creating new deployment configurations, this *could* include separate fields for all of the information that is normally provided by the manifest too. In that case, it would be possible to push without having a manifest by creating a new deployment configuration and setting the fields appropriately, then using that one to deploy.

Comment 3 Malgorzata Janczarska 2014-03-13 11:32:21 EDT

We talked with McQ and we agreed that we shouldn't treat the same application path and other data stored in launch configuration.

This is the algorithm I think would make sense after our conversation:
1. User selects a file/folder in the project and clicks "Deploy"
2. Orion passes the selected path to the plugin
3. Plugin figures out the root path based on the selected path, for instance it goes up in the hierarchy and when it finds a manifest this is the root path to deploy
4. Plugin deploys the application and requests to save the launch configuration that contains the root path found in point 3.

Next time Deploy:
1. User selects a file/folder in the project and clicks "Deploy", doesn't have to be the same as previous scenario
2. Orion goes up in the file hierarchy and checks if there is a launch configuration saved for any of the folder parents
3. If it is it runs this configuration
5. If there is no configuration found for this hierarchy we run the generic Deploy (that will probably ask for some extra details and save it in the launch configuration)

Comment 4 Malgorzata Janczarska 2014-03-20 11:01:05 EDT

First step made: now after the successful deploy the org and space is being saved and the next time we don't ask for the org and space after using Deploy button. From the button's tooltip user may know before starting the deployment what is the target org and space.
This however does not solve the Path matching yet. If there is more then one manifest in the project we will use the last used manifest. Next setp would be using the manifest that can be found in an of the parent folders of the current selection.

Comment 5 Malgorzata Janczarska 2014-04-28 08:19:51 EDT

This is partially fixed in M1: we save the last launch configuration. For M2 we would like to add a context to it: we run the last launch configuration but applicable to the the current file/folder.

Comment 6 Malgorzata Janczarska 2014-09-12 09:10:01 EDT

I don't this we are planning to do more here.