Editor's Note: This issue has been resolved in Winter 19
Figured out the problem. Some Salesforce issue with History tracking was the root cause. Turned off history tracking in dest org and once the history object was eliminated, the object could once again be deployed.
Not sure why there was an issue, though the object label was changed in the source org....
You can do this using just the out-of-the-box Force.com Migration Tool.
As you noted, destroying metadata components is achieved with a destructiveChanges.xml definition. However this differs from package.xml in that it doesn't support wildcards (*) - so the intermediate hurdle is the generation of an explicit definition containing the names of all the ...
In API version 30.0 and later, permissions for required fields can’t be retrieved or deployed. So make sure your profiles/permission sets don't reference any required fields.
See "ProfileFieldLevelSecurity" in the Metadata API Developer's Guide: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_profile.htm
See "fieldPermissions" under "...
I don't know of one to link to for you. I'm not near Jenkins right now, but I think the following is basically accurate.
Follow the directions here to make sure that you have java, ant and the ant-salesforce.jar downloaded and installed or avaiable.
Install Jenkins (these instructions may be easier for you on Windows).
Get Jenkins running (different ...
It'll take some heavy lifting, but you can do this with the metadata API or ANT.
Step 1 Figure out what components are available
Use a describeMetadata() call to get a list of all metadata component types that are available for retrieval. It'll return the name to use in your package.xml, as well as info about if it's stored in a folder. Unfortunately it ...
A hidden gem in the Metadata API deploy operation takes a DeployOptions structure, in it is a purgeOnDelete setting that will do what you need!
purgeOnDelete. If true, the deleted components in the destructiveChanges.xml manifest file aren't stored in the Recycle Bin. Instead, they become immediately eligible for deletion.
This field is available in API ...
Well let's take a look at your deploystage directory
So, this is really interesting. There are two things that pop out right away.
Firstly, it looks like our package.xml file wasn't set up correctly to begin with. The following section:
I got the same error and tried the code below. It worked. The metadata type is CustomLabel not CustomLabels. It's very strange.
Salesforce Metadata Types
You will be able to pull/push the approval process using a the following package.xml. The ApprovalProcess element will pull down the Approval Process and the Workflow element will pull down any of the actions that are referenced in the Approval Process for that action. Replace CustomObject__c with whatever object(s) your approval processes are on, this will ...
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:
Once activated, a flow version can never be modified. In fact, about the only reasonable approach is to delete all paused interviews, deactivate the current flow version, delete all references to the flow, delete the flow entirely, then deploy the flow and all its references back in place.
This restriction exists because if a flow was active, it could have ...
adding password manually after retrieve and before deploy worked :
<?xml version="1.0" encoding="UTF-8"?>
Tests always run in serial during deployments; this helps avoid spurious errors because of CANNOT_LOCK_ROW errors. This is true for the migration tool, package installs (when applicable), and change sets. If you're concerned about running tests for CI, then yes, it would make more sense to deploy, run tests, then undeploy. Salesforce DX will probably make ...
Good question, both these things are not as clear as they should be in the docs. Here are some points that can help you.
Discovering all Metadata Types.
This topic in the documentation gives you the top level types. However you will notice that other types such as CustomField or ValidationRule are not listed. This is due to them being child meta types.
I'm pretty familiar with the Metadata API and deletion of Package 'definitions' is not supported presently it appears. The only thing i can think is accessing the Delete action via the page URL's, which is not ideal of course since its not supported.
I did also try this in destructiveChanges.xml, it did not work sadly. I should clarify, it did not error, ...
You can force a run of all tests when deploying using the Force.com migration tool which is a wrapper over Ant.
Set runAllTests=true when deploying to simulate a production like deployment where all tests are run while deploying.
To rollback if test classes fail, set the rollBackOnError deployment option to true.
Here is the reference documentation, look ...
The migration tool doesn't provide this functionality directly, but it can be built on top of the migration tool. We've built and open sourced our build and automation scripts used at the Salesforce Foundation at https://github.com/SalesforceFoundation/CumulusCI
Assuming you already have a repository with your metadata contained in the src directory, you ...
I just had some invisible character ( ​ Unicode Character 'ZERO WIDTH SPACE' (U+200B) http://...
EmailTemplate does not support the wildcard operator; you will have to individually name each template. See the docs at http://www.salesforce.com/us/developer/docs/daas/Content/daas_package.htm for constructing a project manifest for a complete list of which objects do and do not support wildcards.
If you can use the command-line versions of these tools, then you could wrap all of this up with a script and set it to run on a schedule (cron or other). I didn't test this, but this would be a bash (OSX, Linux, Unix) version of what you could do...
# clear out existing code
# this is important to capture deletes
rm -rf src/*
# run ant
You can retrieve and deploy all types of Lightning metadata, including Components, Applications, Interfaces, and Events, from/to any org using the Force.com Migration Tool, by deploying/retrieving the AuraDefinitionBundle metadata type.
I have gotten this to work using the API v35 version of the Force.com Migration Tool --- I don't know whether it works ...
As it turns out, I needed to update my package.xml version to 38.0. After doing so, the process retrieved fine.
I cannot say for sure but I believe the issue was due to the offending process being marked as Invocable, which may be incompatible with version 36.0 of the API.
Yes, GlobalPicklist has been replaced by GlobalValueSet. This is outlined in the relevant documentation and was mentioned in the release notes.
Streamlined Metadata API for Picklists
We bring you elegance and efficiency with a reimagined Metadata API for picklists, with no wasted elements to clutter your API calls. The new structure clearly ...
there is a dedicated metadata for such standard picklist field StandardValueSet mappings between field names and standardvalueset names can be explored here
so to retrieve/deploy Opportunity.StageName field you need to have the following lines in your package.xml
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 ...
We just got done building our CI infrastructure around the next release of the Nonprofit Starter Pack at the Salesforce.com Foundation. We open sourced all the documentation including the Jenkins configurations and scripts used as well as a custom webapp (mrbelvedere) we deploy on Heroku and use for some custom logic not possible directly in Jenkins:
Workflow Rules have their own component type, as do Workflow Tasks, try this...
<?xml version="1.0" encoding="UTF-8"?>
There is Test.loadData() which can be used to load a number of testing records from a CSV file stored as a static resource.
This is great if the intention of the data is for running automated test cases. Not so useful if you want to setup an org for an actual user.