Edit multiple files - Command-S (save All) - only one file seems to get processed

[eric.k...@helix.com]

This is probably a newbie IntelliJ/IC question but ....

I change two Apex files (one dependent on the other) and click Command-S (Save All). In the event log, only one of the two files seems to be sent to the compiler.

Deployment Complete Deployed 0/1 components to ....
Deployment Failed
  ERROR deploying ApexClass classes/Foo.cls some compiler error

And of course, because only one of the changed files was attempted to be deployed (0/1), the dependency isn't resolved. 

This is super frustrating as in Eclipse Force.com IDE, Save All sent all changed files to be deployed and dependencies were easy to fix in one go.

Other observations:

1. IC 2.0.1.7

2. I did not edit the default IC Validation and Deployment preference 'Override Save All Action' - it is unchecked and "Deploy all modified files" is checked/greyed

3. For some reason, IC seems to attempt to auto-deploy changes to my file in the middle of editing, before I even click Command-S. 

 

[Scott]

Hi, Eric. Let me explain how those options work together so the observed behavior will hopefully make more sense:

• Override Save All action - By default IntelliJ IDEA/WebStorm wants to optimize the Save All action that is trigger when you type Cmd+S/Ctrl+S. If it thinks there are no differences between the contents of the editor and the physical file associated with that editor, you can type Cmd+S/Ctrl+S all you want and nothing will happen. That's unfortunate because Illuminated Cloud registers for the resulting event so that it can perform deploy-on-save behavior. As a result, IC ships with an alternative Save All action that, when used, always performs a deploy-on-save when the action is triggered, whether by keyboard shortcut, toolbar button, or menu item. It's not enabled by default because JetBrains isn't real keen on plugins overriding default system behavior, but I do recommend that all users enable this option because it just makes things work the way you'd expect. Note that for non-IC files, it has the exact same behavior as the standard Save All action.
• Deploy all modified files - Assuming you enable Override Save All action, this determines which file(s) are deployed when you perform a Save All. If checked, any files that the base IDE thinks are "dirty" relative to the filesystem are saved as well as the currently active file even if the IDE doesn't think it's dirty. If unchecked, only the currently active file is deployed.
• Deploy on save - For any of the above behavior to work, you must enable this. Some folks prefer to have fine-grained control over when deployments take place, though, so they disable this and use the bulk deployment actions to push data to the server.

The entire deploy-on-save concept is really intended to be used for fast cycle work in a single file. If you're making changes to multiple files at once, you likely want to use the bulk deployment actions, Deploy Modified Metadata or Deploy All Metadata. The former is what you want most of the time as it compare local filesystem timestamp information to server metadata timestamp information to decide what subset of metadata is out-of-date, then deploys that subset to the server. The latter will deploy the selected files without checking to see whether they're out of date. In your example where you'd modified multiple files, you would want to use Deploy Modified Metadata and all of the files will be included. If some succeed and some fail, the next Deploy Modified Metadata will include the failed metadata as well as any metadata that was modified in the interim.

There is an open enhancement request to allow the overridden Save All action to be configured to perform a Deploy Modified Metadata on the module or project without any intermediate dialog. I very much like that idea and plan to implement it soon.

I hope that helps explain how these various configuration options and related deployment actions work. You can find more details about metadata deployment and retrieval in Illuminated Cloud here:

http://www.illuminatedcloud.com/home/deployment

Regards,

Scott Wells

[Roy Mayfield]

Hi Scott, I have use cases where I want to modify locally layouts, objects and classes.  I have tried to use the 'bulk' deploy, but I can't seem to be able to deploy a group of different metadata file types in a single deployment. i.e. create the package.xml just for the files modified locally.  More importantly I want to be able to *preview* the locally-modified files using the time-diff, but I can't figure out how to a). preview, b), from the modded list, select or unselect, then finally deploy a subset of the locally modded files in a single deployment.  Can this be done?  Thanks, -Roy

[Roy Mayfield]

PS - the closest I have gotten is to do "custom", but I need to select manually without the help of a pre-selection based on time-diff

[Scott]

Roy, let me repeat back what I think I'm hearing from you here to make sure we're having the same discussion. It sounds like you're asking if there's a way to have the deploy dialog pre-populated with the set of "dirty" files across multiple metadata types, correct? Please let me know if that's a correct interpretation or not so that I can make sure to respond to the right question.

Regards,

Scott

[Roy Mayfield]

Yes Scott, that is the question.  Thanks, -Roy

[Scott]

Okay, thanks for confirming. Currently that's not possible. The reason is that the API calls required to check which metadata is dirty relative to the server can be quite expensive in densely-populated orgs. As a result, IC only computes that once you've committed to the deployment operation. It's then able to optimize the required API calls based on the metadata that was selected for deployment in the dialog instead of having to check every possible metadata object. I didn't want the dialog to lag for seconds or potentially minutes every time you opened it for deployment.

Now, having said that, that design decision was made before I put some other significant optimizations in place around how those expensive API calls are made, in particular parallel request processing. It's possible that a check as the dialog is opening would provide a better experience now in most orgs, though I know that some orgs are still REALLY slow to respond to these APIs due to the sheer volume of metadata they contain.

So that's probably more detail than you wanted, but that's how it works today and why it works that way.

Regards,

Scott

[Roy Mayfield]

Thanks Scott.  I misunderstood the dirty scope.  Is there a way for IC2 to detect if a file has changed locally in content or by timestamp from the time in which was originally downloaded from the Org using IC2? (i.e. I copy a class from another directory *externally* [using windows explorer] that has different content or timestamp).  I know we are on dead horse territory but I seemed like a good way to complete the topic.  Thanks! -Roy

[Scott]

Roy, interestingly that's something that a user asked for very early on in IC's lifecycle. I thought there was an existing enhancement request in the issue tracker but have been unable to find it. I think it's reasonable to ask for a "dry run" dirty check that compares local filesystem last mod times against known last successful retrieval/deployment times. If that's something that interests you, please log an enhancement request in the issue tracker to ensure it's squarely on my radar (unlike the other one that I can no longer find!).

Regards,

Scott

[eric.k...@helix.com]

Scott -- returning to this thread

IC 2.0.2.5

Languages & Frameworks > Illuminated Cloud

Override Save All action: checked

- Deploy all modified files: checked

Deploy on save: checked

- Deploy on external change: unchecked

- Deploy static resource bundle on contents change: checked

Prefer Tooling API for

- Apex: Checked

Use case:

Two files:

- Bar.cls

- Foo.cls

Edit each file, introduce syntax error into Foo.cls, then Command-S (Save all)

IC2 shows message in status bar - deploying Bar.cls, Foo.cls

Messages panel shows

Successes

=======

Bar.cls

Failures 

=======

Foo.cls

But this is misleading - Bar.cls compiled OK but wasn't deployed to the org. If you go to fix Foo.cls and Command-S, Foo.cls is compiled and deployed to the org but the org's Bar.cls does not represent the latest version in the project. You have to "touch" Bar.cls and Command-S again to commit the changes to the org. If you were editing 5 files and 4 "succeeded", you need to touch all four again.

Either I'm doing something wrong or the messages panel should read something like this

Successes (but not deployed)

==============

Bar.cls

Failures

=======

Foo.cls

and there should be an easy way that after you fix Foo.cls, that all of the successes-but-not-deployed can be automatically added to the compile/deploy package on the next Command-S so you don't have to "touch" those files again.

[Scott]

Eric, when IC deploys multiple files, it does so with a flag that specifies that partial success/commit is allowed. In the example you provided, Bar should have been both compiled and deployed in the first deployment. It sounds like that's not happening, though, and that it's rolling back the deployment on any failure in the payload. The rest of the described behavior is based on the assumption that it works that way. If it doesn't, everything downstream kind of falls apart. I'll need to try to reproduce the behavior that you're seeing and, assuming that I can, try to understand why it's happening that way. Let me dig in a bit and I'll let you know what I find.

Regards,

Scott

[Scott]

Hey, folks. I want to refer you to the following issue in the public issue tracker on this same topic:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/978

I've been able to reproduce the behavior that you're seeing. To me it appears to be a regression in the Tooling API, though I'm not 100% sure about that. I've contacted Salesforce to see if I can get confirmation or that or not. Minimally I'll plan to make some adjustments based on the current observed API behavior so that state tracking across Deploy Modified Files works properly given how partial success deployments are being reported.

Regards,

Scott