Failed "Save" of Apex Source Files does not re-save them on subsequent attempts
Issue #1265
resolved
Unsure if this is a bug ... but in my Illuminated Cloud plugin (v1.x) I've got it configured to "deploy all modified files" (as per screenshot), so Cmd+S saves any apex files I've changed since I last deployed.
If I change (say) 3 related apex classes and press Cmd+S, it attempts to deploy them onto the sandbox. If this works - all good. If I get back a "FAIL" or "PARTIAL SUCCESS" message, and then fix the one file containing the error and press Cmd+S again, it only tries to save that one apex file rather than all 3 again, and I normally end up with a further error due to dependencies between the files.
If I then go and make a (minor) edit to all 3 files to change the last-modified-timestamp, then it'll try to save them all again the next time I press Cmd+S.
It's like its updating its "last-successful-deployment-timestamp" prematurely when a deployment fails. Is this a bug or is there something I can change to work around this problem?
Comments (8)
-
repo owner
-
reporter
Hi Scott, any joy with this one? Did you manage to duplicate it? No problems if its low-priority, I can work around it for now. Thanks.
-
repo owner
Corey, this week and last week have been insane as I wind down from my current day job and prep for going 100% full-time on IC starting next week. I'll definitely take a look at this next week and let you know what I find.
-
repo owner
Corey, can you update to the latest build and see if you still have the problem? A build or two back I found and fixed an issue with how IC tracks the state that it uses to determine which subset of metadata requires deployment. I'm hoping this is fixed now, but if not that would be good to know as well.
-
reporter
Hi Scott - I’ve got v1.8.4.9 installed. I’ve had a quick play with two new classes (ClassOne and ClassTwo) and a function in ClassOne that calls a function in ClassTwo, but ClassOne has a deliberate syntax error:
- I pressed command-S, which tried to save both ClassOne and ClassTwo;
- It came back with an error on ClassOne;
- I fixed the error on ClassOne and pressed command-S again, without touching ClassTwo;
- It tried to save both ClassOne and ClassTwo again.
So thats good - it didn’t ignore the saving of ClassTwo any more.
I’ll have a bit more of a play with it in the coming says and see how it goes. If you don’t hear back from me we can call it “Solved” I think.
-
repo owner
Corey, I'd be surprised if it was fixed in IC1. The bugs I fixed were in IC2 (via 2.0.6.1) and I haven't back-ported them. For now I won't try to fix something that may not be broken (or at least not an instance of the reported issue), but if you do see it happen again, let me know and I'll look into back-porting the fix from 2.0.6.1 to IC1.
-
reporter
Ah ok - yeah very strange. I’ll keep an eye on it, its usually pretty obvious when it happens (as a file has not saved that should have). I’ll probably be moving to the v2 plugin at some stage soon.
-
reporter
- changed status to resolved
Hi Scott, I will mark this as Resolved and see if it continues to happen.
- Log in to comment
Hey, Corey. If IC isn't tracking the deployment "dirty" state properly, that's definitely a bug. The goal is that you should be able to rely on IC's notion of what needs to be deployed. Let me try to reproduce a bit and I'll let you know if I need more info from you. Thanks for filing!