Cli: Document Deployment Fails

Created on 25 Jul 2019  路  11Comments  路  Source: forcedotcom/cli

Summary

Deploying Documents via the CLI fails with the message The DocumentFolder named Folder_Name/Document_Name was not found in the workspace.

Steps To Reproduce:

  1. Ensure a Document Folder named MyFolder exists in the source environment, with a Document named MyDocument.txt inside.
  2. Using the following package.xml, perform a force:source:retrieve
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <name>Document</name>
    <members>MyFolder</members>
    <members>MyFolder/MyDocument.txt</members>
  </types>
  <version>46.0</version>
</Package>
  1. Using the same manifest, attempt to deploy the Document and Folder.

Expected result

_The Document and Folder were deployed_.

Actual result

_You receive the error message The DocumentFolder named MyFolder/MyDocument.txt was not found in the workspace._

Additional information

_Feel free to attach a screenshot_.

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): 7.15.3

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core): 46.6.0

OS and version: Windows 10 Pro

bug

Most helpful comment

If you remove the file extension (.txt) it should work. Deploy does not take the file extension

All 11 comments

Clarification for step 3: Attempt to deploy the metadata to a sandbox using force:source:deploy

If you remove the file extension (.txt) it should work. Deploy does not take the file extension

Hi @clairebianchi ! I appreciate your response. I did try both ways (with and without the file extension), although I wasn't 100% on which was the supported path, and was having trouble finding documentation.

I re-attempted deploying using the following command:

sfdx force:source:deploy -c -u myAlias -x path/to/package.xml

With the following package.xml (no file extension on file name):

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <name>Document</name>
    <members>MyFolder</members>
    <members>MyFolder/MyDocument</members>
  </types>
  <version>46.0</version>
</Package>

And received the following error: The DocumentFolder named MyFolder/MyDocument was not found in the workspace.

Can you re-open this issue, or can I provide more information/open a new issue to assist?

@kristen-j-owens, I am sorry about that. I have added the bug to our backlog and hope to have the issue picked up by the team in August.

Great, thanks for the update!

@clairebianchi Any updates on this? August has come and gone and so has most of September :-P

After some hacking, we were able to get the Documents to deploy by adding the file extension to the document-meta.xml

For example, for this:

    <types>
        <members>PatronTicket_Application_Components</members>
        <members>PatronTicket_Application_Components/PatronTicketLogo.gif</members>
        <name>Document</name>
    </types>

Our source tree contains:

```
force-app\
main\
default\
documents\
PatronTicket_Application_Components.documentFolder-meta.xml
PatronTicket_Application_Components\
PatronTicketLogo.gif.document-meta.xml
PatronTicketLogo.gif (the actual binary)

````

@daveespo , I believe this had been fixed a while back and was specific to windows OS.Are you still facing any issues during deployment using package.xml? If yes, could you please provide the CLI version and the OS you are using and the error message you get during deploy? Thank you.

@nramyasri-sf I don't think this is fixed. We're seeing different behavior between force:source:deploy using a manifest (package.xml) and force:source:push to a scratch org.

For force:source:deploy, we need the document-meta.xml to also contain the file extension as part of its filename (as I show above in my example)

For force:source:push, the push will fail with:

     [java]     "name": "Missing Metadata File",
     [java]     "message": "Expected metadata file with '-meta.xml' extension at path: C:\\Users\\x\\y\\z\\q\\force-app\\main\\default\\documents\\PatronTicket_Application_Components\\BoxOfficeReportsIcon.document-meta.xml",

So, which is it? Should the meta.xml file have the file extension for the document in its filename or not?

@daveespo , source:deploy using -x references the package.xml and a format shown below should suffice :

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <name>Document</name>
    <members>foldername/filename</members>
  </types>
  <version>46.0</version>
</Package>

source:push does not reference to any package.xml within the project folder. I am unsure as to where you had removed the file extensions. You need not make any changes to document-meta.xml while using source:deploy or source:push. Let me know if that answered your question. Thanks.

@nramyasri-sf -- our project still needs to serve two masters. It is a 1GP managed package and thus we need to be able to use BOTH force:source:deploy (to push into our packager org) while being able to use force:source:push into scratch orgs.

This is apparently where the breakdown occurs. The CLI builds the deployment differently (push vs. deploy) and one requires the file extension while the other doesnt.

Was this page helpful?
0 / 5 - 0 ratings