Cfrgtkky

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:

1. : 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?

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 (re)learn?
Use the singlePackage setting correctly when deploying a single package!