I'm starting to use ANT to deploy changes to my SF org.
Can I delete and edit custom fields using the ANT Migration Tool.
In the documentation I only found how to delete the entire object
[SalesForce] Deleting/Editing fields with Migration Tool
Related Solutions
I did encounter the dreaded "An unknown exception has occurred" too; but it was when using related lookup filters which used reference fields to lookup to a 3rd object. The dependency checker in salesforce doenst seem to look beyound 1 level deep. I logged a case with them, which they accepted as an issue, are are trying to resolve.
My solution (i've not yet implemented) was to add logic in the scripts first step that edits page layouts and deploys them back prior to delete, to also clean up various things from .object files first too (related lookup filters, and perhaps rollup summary fields under simliar conditions). Then they undeployment should be allowed, this in principle though is very tricky due to the code possibly referencing these fields. So it thus is also necerssary to edit every class, trigger, page and empty them out and deploy too. I have some logic to do this, and will try and update the git hub repo soon.
Eric Wilcox (developer of the undeploy script)
Edit: Summer '15 made this "all better". If you upgrade your ant-salesforce.jar to one that supports API version 34, you can now pass a "testLevel=RunLocalTests" attribute to sf:deploy like so:
<sf:deploy
testLevel="RunLocalTests"
username="${sf.username}"
password="${sf.password}"
serverUrl="${sf.server}"
deployRoot="src"
/>
From the docs:
As part of this change, the runAllTests deployment option is now replaced with testLevel. You can choose which tests to run in a deployment by setting the desired test level. For a description of all test levels, see test levels for the deploy() call. In particular, to run a subset of tests in a deployment, set testLevel to the RunSpecifiedTests value and specify the tests to run in the runTests option.
And
RunLocalTests—All tests in your organization are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.
This was the workaround for pre-Summer '15 for posterity:
Because I killed off the better part of a day hacking around in ant to accomplish the workaround @pepefloyd suggested, I wanted to publish a working example; In my case, the test classes are prefixed with "Test_" but you can fool around with the fileset as necessary
This is tested against v30 of the Force.com ant migration tool
<target name="test">
<sfCompileAndTestUnmanaged checkOnly="true" username="${sf.username}" password="${sf.password}" server="${sf.server}">
<fileset dir="src/classes">
<include name="**/Test_*.cls"/>
</fileset>
</sfCompileAndTestUnmanaged>
</target>
<scriptdef name="sfCompileAndTestUnmanaged" language="javascript">
<attribute name="checkonly"/>
<attribute name="username"/>
<attribute name="password"/>
<attribute name="server"/>
<attribute name="trace"/>
<element name="fileset" type="fileset"/>
<![CDATA[
var filesets = elements.get("fileset");
var filesetsIterator = filesets.iterator();
var projectClasses = [];
while(filesetsIterator.hasNext()){
var fs = filesetsIterator.next();
var iter = fs.iterator();
while(iter.hasNext()){
var resource = iter.next();
var clazz = resource.getName().replace(".cls","");
self.log("CLASS: " + clazz);
projectClasses.push(clazz);
}
}
var task = project.createTask("antlib:com.salesforce:compileAndTest");
task.setCheckonly(attributes.get("checkonly") == 'true');
task.setUsername(attributes.get("username"));
task.setPassword(attributes.get("password"));
task.setServer(attributes.get("server"));
task.setTrace(attributes.get("trace") == 'true');
//I tried 'importPackage' and conventional instantiation but couldn't get the inner class to instantiate; this works though
var testsElement = task.getClass().getClassLoader().loadClass("com.salesforce.ant.CompileAndTest$RunTestsElement").newInstance();
task.addRunTests(testsElement);
var classClazz = task.getClass().getClassLoader().loadClass("com.salesforce.ant.CompileAndTest$CodeNameElement");
for(i in projectClasses){
var clazz = classClazz.newInstance();
clazz.addText(projectClasses[i]);
testsElement.addClass(clazz);
}
task.execute();
]]>
</scriptdef>
Alternatively, we've actually used a version of 'deploy' that does a no-op deploy (the package.xml in the 'ant' directory is empty except for the <version>
element. This gives us incremental updates as the tests are running and allows the deployment of the source files to succeed in a separate ant target (not described below) while the tests may fail (insufficient code coverage, failing assertions, etc.)
<target name="test">
<sfDeployUnmanaged purgeOnDelete="true" ignoreWarnings="true" username="${sf.username}" password="${sf.password}" serverUrl="${sf.server}" deployRoot="ant" maxPoll="75">
<fileset dir="src/classes">
<include name="**/*.cls"/>
</fileset>
</sfDeployUnmanaged>
</target>
<scriptdef name="sfDeployUnmanaged" language="javascript">
<attribute name="purgeondelete"/>
<attribute name="ignorewarnings"/>
<attribute name="username"/>
<attribute name="password"/>
<attribute name="serverurl"/>
<attribute name="deployroot"/>
<attribute name="maxpoll"/>
<attribute name="trace"/>
<element name="fileset" type="fileset"/>
<![CDATA[
var filesets = elements.get("fileset");
var filesetsIterator = filesets.iterator();
var projectClasses = [];
while(filesetsIterator.hasNext()){
var fs = filesetsIterator.next();
var iter = fs.iterator();
while(iter.hasNext()){
var resource = iter.next();
var clazz = resource.getName().replace(".cls","");
self.log("CLASS: " + clazz);
projectClasses.push(clazz);
}
}
var task = project.createTask("antlib:com.salesforce:deploy");
task.setPurgeOnDelete(attributes.get("purgeondelete") == 'true');
task.setIgnoreWarnings(attributes.get("ignorewarnings") == 'true');
task.setUsername(attributes.get("username"));
task.setPassword(attributes.get("password"));
task.setServerURL(attributes.get("serverurl"));
task.setDeployRoot(attributes.get("deployroot"));
task.setMaxPoll(attributes.get("maxpoll"));
task.setTrace(attributes.get("trace") == 'true');
//Blows up when build timeout is reached if we don't set this (it uses this value when formatting the exception it throws)
task.setOwningTarget(self.owningTarget);
var classClazz = task.getClass().getClassLoader().loadClass("com.salesforce.ant.DeployTask$CodeNameElement");
for(i in projectClasses){
var clazz = classClazz.newInstance();
clazz.addText(projectClasses[i]);
task.addRunTest(clazz);
}
task.execute();
]]>
</scriptdef>
Best Answer
Yes, you can specify individual fields in the package.xml (for deploy) and destructivechanges.xml (for deletion)
The syntax is as follows
A great reference for finding the different types you can deploy, and more about the migration tool in general, is http://www.salesforce.com/us/developer/docs/daas/salesforce_migration_guide.pdf