Metadata API deployments are failing in Spring '19
For some time now (several years) I've been deploying changes to Apex classes using the Metadata API deploy web method with an associated zip file containing the metadata and package.xml file.
This morning when I tried to deploy to na87 on Spring 19 with patch 11.5 it failed with the message:
- : package.xml (classes/package.xml) (line:0 column:0)
No package.xml found
I double checked the zip file I was sending in. It had the structure:
- classes/TheApexClassToDeploy.cls
- classes/TheApexClassToDeploy.cls-meta.xml
- package.xml
The package.xml had:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>TheApexClassToDeploy</members>
<name>ApexClass</name>
</types>
<version>45.0</version>
</Package>
It isn't clear to me why this package format isn't correct anymore. Did I miss something in the release notes?
Based on the error message I took a punt and created this package.xml file in the classes folder:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>45.0</version>
</Package>
Which seemed to allow the deploy to proceed.
I'll go down the path of raising a support case for this, but I'd be interested to know if I've missed a documented change to the Metadata API format.
Verification in Workbench migration/deploy using v45.0:
If I change the root level package.xml from:
<version>45.0</version>
to:
<version>44.0</version>
The deploy works against the v45.0 Metadata API endpoint.
As suggested by Pranay I did a retrieve via Workbench using v45.0 with the package.xml file and "Single Package" checked.
It doesn't appear to have the additional package.xml file.
I then did a Metadata deploy with the resulting zip file. It failed in the same way as it did above. I then tired again, but checked "Single Package"... and it deployed.
Maybe they are enforcing something new around the singlePackage
setting?
metadata-api spring19
|
show 3 more comments
For some time now (several years) I've been deploying changes to Apex classes using the Metadata API deploy web method with an associated zip file containing the metadata and package.xml file.
This morning when I tried to deploy to na87 on Spring 19 with patch 11.5 it failed with the message:
- : package.xml (classes/package.xml) (line:0 column:0)
No package.xml found
I double checked the zip file I was sending in. It had the structure:
- classes/TheApexClassToDeploy.cls
- classes/TheApexClassToDeploy.cls-meta.xml
- package.xml
The package.xml had:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>TheApexClassToDeploy</members>
<name>ApexClass</name>
</types>
<version>45.0</version>
</Package>
It isn't clear to me why this package format isn't correct anymore. Did I miss something in the release notes?
Based on the error message I took a punt and created this package.xml file in the classes folder:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>45.0</version>
</Package>
Which seemed to allow the deploy to proceed.
I'll go down the path of raising a support case for this, but I'd be interested to know if I've missed a documented change to the Metadata API format.
Verification in Workbench migration/deploy using v45.0:
If I change the root level package.xml from:
<version>45.0</version>
to:
<version>44.0</version>
The deploy works against the v45.0 Metadata API endpoint.
As suggested by Pranay I did a retrieve via Workbench using v45.0 with the package.xml file and "Single Package" checked.
It doesn't appear to have the additional package.xml file.
I then did a Metadata deploy with the resulting zip file. It failed in the same way as it did above. I then tired again, but checked "Single Package"... and it deployed.
Maybe they are enforcing something new around the singlePackage
setting?
metadata-api spring19
2
Can you try removingstandalone="true"
, in package.xml ?
– Pranay Jaiswal
4 hours ago
According to docs, standalone can have only 2 possible values, yes and no. Making it true might make XML invalid and give you errors. msdn.microsoft.com/en-us/library/ms256048(v=vs.110).aspx
– Pranay Jaiswal
4 hours ago
@PranayJaiswal Good catch. I checked my actual package.xml file and it has<?xml version="1.0" encoding="utf-8" standalone="yes"?>
. I'm not sure I ended up with=true
in my example.
– Daniel Ballinger
3 hours ago
1
Can you provide the samepackage.xml
in retrevie command and see whats the file structure of retreived zip ?
– Pranay Jaiswal
3 hours ago
1
You found solution. I believe you should be the one answering :)
– Pranay Jaiswal
3 hours ago
|
show 3 more comments
For some time now (several years) I've been deploying changes to Apex classes using the Metadata API deploy web method with an associated zip file containing the metadata and package.xml file.
This morning when I tried to deploy to na87 on Spring 19 with patch 11.5 it failed with the message:
- : package.xml (classes/package.xml) (line:0 column:0)
No package.xml found
I double checked the zip file I was sending in. It had the structure:
- classes/TheApexClassToDeploy.cls
- classes/TheApexClassToDeploy.cls-meta.xml
- package.xml
The package.xml had:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>TheApexClassToDeploy</members>
<name>ApexClass</name>
</types>
<version>45.0</version>
</Package>
It isn't clear to me why this package format isn't correct anymore. Did I miss something in the release notes?
Based on the error message I took a punt and created this package.xml file in the classes folder:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>45.0</version>
</Package>
Which seemed to allow the deploy to proceed.
I'll go down the path of raising a support case for this, but I'd be interested to know if I've missed a documented change to the Metadata API format.
Verification in Workbench migration/deploy using v45.0:
If I change the root level package.xml from:
<version>45.0</version>
to:
<version>44.0</version>
The deploy works against the v45.0 Metadata API endpoint.
As suggested by Pranay I did a retrieve via Workbench using v45.0 with the package.xml file and "Single Package" checked.
It doesn't appear to have the additional package.xml file.
I then did a Metadata deploy with the resulting zip file. It failed in the same way as it did above. I then tired again, but checked "Single Package"... and it deployed.
Maybe they are enforcing something new around the singlePackage
setting?
metadata-api spring19
For some time now (several years) I've been deploying changes to Apex classes using the Metadata API deploy web method with an associated zip file containing the metadata and package.xml file.
This morning when I tried to deploy to na87 on Spring 19 with patch 11.5 it failed with the message:
- : package.xml (classes/package.xml) (line:0 column:0)
No package.xml found
I double checked the zip file I was sending in. It had the structure:
- classes/TheApexClassToDeploy.cls
- classes/TheApexClassToDeploy.cls-meta.xml
- package.xml
The package.xml had:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>TheApexClassToDeploy</members>
<name>ApexClass</name>
</types>
<version>45.0</version>
</Package>
It isn't clear to me why this package format isn't correct anymore. Did I miss something in the release notes?
Based on the error message I took a punt and created this package.xml file in the classes folder:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<version>45.0</version>
</Package>
Which seemed to allow the deploy to proceed.
I'll go down the path of raising a support case for this, but I'd be interested to know if I've missed a documented change to the Metadata API format.
Verification in Workbench migration/deploy using v45.0:
If I change the root level package.xml from:
<version>45.0</version>
to:
<version>44.0</version>
The deploy works against the v45.0 Metadata API endpoint.
As suggested by Pranay I did a retrieve via Workbench using v45.0 with the package.xml file and "Single Package" checked.
It doesn't appear to have the additional package.xml file.
I then did a Metadata deploy with the resulting zip file. It failed in the same way as it did above. I then tired again, but checked "Single Package"... and it deployed.
Maybe they are enforcing something new around the singlePackage
setting?
metadata-api spring19
metadata-api spring19
edited 1 hour ago
Daniel Ballinger
asked 4 hours ago
Daniel BallingerDaniel Ballinger
73.5k15150396
73.5k15150396
2
Can you try removingstandalone="true"
, in package.xml ?
– Pranay Jaiswal
4 hours ago
According to docs, standalone can have only 2 possible values, yes and no. Making it true might make XML invalid and give you errors. msdn.microsoft.com/en-us/library/ms256048(v=vs.110).aspx
– Pranay Jaiswal
4 hours ago
@PranayJaiswal Good catch. I checked my actual package.xml file and it has<?xml version="1.0" encoding="utf-8" standalone="yes"?>
. I'm not sure I ended up with=true
in my example.
– Daniel Ballinger
3 hours ago
1
Can you provide the samepackage.xml
in retrevie command and see whats the file structure of retreived zip ?
– Pranay Jaiswal
3 hours ago
1
You found solution. I believe you should be the one answering :)
– Pranay Jaiswal
3 hours ago
|
show 3 more comments
2
Can you try removingstandalone="true"
, in package.xml ?
– Pranay Jaiswal
4 hours ago
According to docs, standalone can have only 2 possible values, yes and no. Making it true might make XML invalid and give you errors. msdn.microsoft.com/en-us/library/ms256048(v=vs.110).aspx
– Pranay Jaiswal
4 hours ago
@PranayJaiswal Good catch. I checked my actual package.xml file and it has<?xml version="1.0" encoding="utf-8" standalone="yes"?>
. I'm not sure I ended up with=true
in my example.
– Daniel Ballinger
3 hours ago
1
Can you provide the samepackage.xml
in retrevie command and see whats the file structure of retreived zip ?
– Pranay Jaiswal
3 hours ago
1
You found solution. I believe you should be the one answering :)
– Pranay Jaiswal
3 hours ago
2
2
Can you try removing
standalone="true"
, in package.xml ?– Pranay Jaiswal
4 hours ago
Can you try removing
standalone="true"
, in package.xml ?– Pranay Jaiswal
4 hours ago
According to docs, standalone can have only 2 possible values, yes and no. Making it true might make XML invalid and give you errors. msdn.microsoft.com/en-us/library/ms256048(v=vs.110).aspx
– Pranay Jaiswal
4 hours ago
According to docs, standalone can have only 2 possible values, yes and no. Making it true might make XML invalid and give you errors. msdn.microsoft.com/en-us/library/ms256048(v=vs.110).aspx
– Pranay Jaiswal
4 hours ago
@PranayJaiswal Good catch. I checked my actual package.xml file and it has
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
. I'm not sure I ended up with =true
in my example.– Daniel Ballinger
3 hours ago
@PranayJaiswal Good catch. I checked my actual package.xml file and it has
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
. I'm not sure I ended up with =true
in my example.– Daniel Ballinger
3 hours ago
1
1
Can you provide the same
package.xml
in retrevie command and see whats the file structure of retreived zip ?– Pranay Jaiswal
3 hours ago
Can you provide the same
package.xml
in retrevie command and see whats the file structure of retreived zip ?– Pranay Jaiswal
3 hours ago
1
1
You found solution. I believe you should be the one answering :)
– Pranay Jaiswal
3 hours ago
You found solution. I believe you should be the one answering :)
– Pranay Jaiswal
3 hours ago
|
show 3 more comments
1 Answer
1
active
oldest
votes
As per the discussion with Pranay in the comments, the cause of the issue was the "singlePackage" setting in the deploy options.
Indicates whether the specified .zip file points to a directory structure with a single package (true) or a set of packages (false).
Typically my deployment tooling would have this set to true (and then would work fine with v45.0), but somehow I'd managed to set it to false.
With "singlePackage" set to false
but a package zip file for a single package against v44.0 the deploy would still be successful. My assumption here is that Salesforce was examining the actual contents of the zip file and adjusting the settings accordingly.
With v45.0 that no longer appears to be the case. singlePackage
must be set to true
when deploying a single package. Otherwise it will fail while looking for the expected package.xml files for the inner packages.
Oddly, it will still work with v45.0 if the inner package.xml files are empty and the root package.xml was valid for the single package.
So what did we learn?
Use the singlePackage
setting correctly when deploying a single package!
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f252340%2fmetadata-api-deployments-are-failing-in-spring-19%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As per the discussion with Pranay in the comments, the cause of the issue was the "singlePackage" setting in the deploy options.
Indicates whether the specified .zip file points to a directory structure with a single package (true) or a set of packages (false).
Typically my deployment tooling would have this set to true (and then would work fine with v45.0), but somehow I'd managed to set it to false.
With "singlePackage" set to false
but a package zip file for a single package against v44.0 the deploy would still be successful. My assumption here is that Salesforce was examining the actual contents of the zip file and adjusting the settings accordingly.
With v45.0 that no longer appears to be the case. singlePackage
must be set to true
when deploying a single package. Otherwise it will fail while looking for the expected package.xml files for the inner packages.
Oddly, it will still work with v45.0 if the inner package.xml files are empty and the root package.xml was valid for the single package.
So what did we learn?
Use the singlePackage
setting correctly when deploying a single package!
add a comment |
As per the discussion with Pranay in the comments, the cause of the issue was the "singlePackage" setting in the deploy options.
Indicates whether the specified .zip file points to a directory structure with a single package (true) or a set of packages (false).
Typically my deployment tooling would have this set to true (and then would work fine with v45.0), but somehow I'd managed to set it to false.
With "singlePackage" set to false
but a package zip file for a single package against v44.0 the deploy would still be successful. My assumption here is that Salesforce was examining the actual contents of the zip file and adjusting the settings accordingly.
With v45.0 that no longer appears to be the case. singlePackage
must be set to true
when deploying a single package. Otherwise it will fail while looking for the expected package.xml files for the inner packages.
Oddly, it will still work with v45.0 if the inner package.xml files are empty and the root package.xml was valid for the single package.
So what did we learn?
Use the singlePackage
setting correctly when deploying a single package!
add a comment |
As per the discussion with Pranay in the comments, the cause of the issue was the "singlePackage" setting in the deploy options.
Indicates whether the specified .zip file points to a directory structure with a single package (true) or a set of packages (false).
Typically my deployment tooling would have this set to true (and then would work fine with v45.0), but somehow I'd managed to set it to false.
With "singlePackage" set to false
but a package zip file for a single package against v44.0 the deploy would still be successful. My assumption here is that Salesforce was examining the actual contents of the zip file and adjusting the settings accordingly.
With v45.0 that no longer appears to be the case. singlePackage
must be set to true
when deploying a single package. Otherwise it will fail while looking for the expected package.xml files for the inner packages.
Oddly, it will still work with v45.0 if the inner package.xml files are empty and the root package.xml was valid for the single package.
So what did we learn?
Use the singlePackage
setting correctly when deploying a single package!
As per the discussion with Pranay in the comments, the cause of the issue was the "singlePackage" setting in the deploy options.
Indicates whether the specified .zip file points to a directory structure with a single package (true) or a set of packages (false).
Typically my deployment tooling would have this set to true (and then would work fine with v45.0), but somehow I'd managed to set it to false.
With "singlePackage" set to false
but a package zip file for a single package against v44.0 the deploy would still be successful. My assumption here is that Salesforce was examining the actual contents of the zip file and adjusting the settings accordingly.
With v45.0 that no longer appears to be the case. singlePackage
must be set to true
when deploying a single package. Otherwise it will fail while looking for the expected package.xml files for the inner packages.
Oddly, it will still work with v45.0 if the inner package.xml files are empty and the root package.xml was valid for the single package.
So what did we learn?
Use the singlePackage
setting correctly when deploying a single package!
answered 3 hours ago
Daniel BallingerDaniel Ballinger
73.5k15150396
73.5k15150396
add a comment |
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f252340%2fmetadata-api-deployments-are-failing-in-spring-19%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Can you try removing
standalone="true"
, in package.xml ?– Pranay Jaiswal
4 hours ago
According to docs, standalone can have only 2 possible values, yes and no. Making it true might make XML invalid and give you errors. msdn.microsoft.com/en-us/library/ms256048(v=vs.110).aspx
– Pranay Jaiswal
4 hours ago
@PranayJaiswal Good catch. I checked my actual package.xml file and it has
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
. I'm not sure I ended up with=true
in my example.– Daniel Ballinger
3 hours ago
1
Can you provide the same
package.xml
in retrevie command and see whats the file structure of retreived zip ?– Pranay Jaiswal
3 hours ago
1
You found solution. I believe you should be the one answering :)
– Pranay Jaiswal
3 hours ago