It turns out you can directly retrieve and update changesets directly with the Metadata API.
Via Sean Harrison:
Pro tip: U can retrieve the contents of a change set incl. manifest with the packageNames parameter on
And it really is that simple.
I made a test changeset in a sandbox with a single component:
Note the "Change Set Name" of TestCS
.
Then over to Workbench for a migration retrieve:
Complete the Retrieve and download the resulting package zip file:
As part of the round trip exercise, extract the zip. Note the presence of the OpportunityBatchable.cls
in the classes folder. Modify the package.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>TestCS</fullName>
<description>Test Change Set. Updated locally!</description>
<types>
<members>OpportunityBatchable</members>
<name>ApexClass</name>
</types>
<version>39.0</version>
</Package>
Zip the package back up. In this case it will have the TestCS folder at the root of the zip.
Back in workbench, use migration > Deploy. Select the modified zip file. Check "Auto Update Package". Press Deploy.
Wait for the deployment to complete. Then reload the change set in Salesforce. Observe the updated Description!
So yes, you could build the changeset using Metadata API calls to update the package definition.
Updates via Chuck Liddell:
- Changeset names aren't unique. If there is a duplicate you will be an error:
More that 1 developer package named "X" exists in this organization. Please rename one of packages so that is has a unique name.
- On update, you can't have an empty package and rely on
autoUpdatePackage
. You need to include all the files that form the changeset.