Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Deployment Fails #144

Closed
kristen-j-owens opened this issue Jul 25, 2019 · 13 comments
Closed

Document Deployment Fails #144

kristen-j-owens opened this issue Jul 25, 2019 · 13 comments
Labels
bug Issue or pull request that identifies or fixes a bug

Comments

@kristen-j-owens
Copy link

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

@kristen-j-owens
Copy link
Author

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

@clairebianchi
Copy link
Collaborator

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

@kristen-j-owens
Copy link
Author

kristen-j-owens commented Jul 29, 2019

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?

@clairebianchi clairebianchi reopened this Jul 29, 2019
@clairebianchi
Copy link
Collaborator

@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.

@kristen-j-owens
Copy link
Author

Great, thanks for the update!

@clairebianchi clairebianchi added the bug Issue or pull request that identifies or fixes a bug label Jul 30, 2019
@daveespo
Copy link

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

@daveespo
Copy link

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)

@nramyasri-sf
Copy link
Contributor

@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.

@daveespo
Copy link

daveespo commented Oct 2, 2019

@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?

@nramyasri-sf
Copy link
Contributor

nramyasri-sf commented Nov 18, 2019

@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.

@daveespo
Copy link

@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.

@uip-robot-zz
Copy link

This issue has been linked to a new work item: W-9298084

@mshanemc
Copy link
Contributor

mshanemc commented Jun 1, 2021

is fixed.

@mshanemc mshanemc closed this as completed Jun 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue or pull request that identifies or fixes a bug
Projects
None yet
Development

No branches or pull requests

6 participants