-
Notifications
You must be signed in to change notification settings - Fork 78
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
Comments
Clarification for step 3: Attempt to deploy the metadata to a sandbox using |
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:
With the following package.xml (no file extension on file name):
And received the following error: 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:
Our source tree contains:
|
@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:
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 :
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 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. |
This issue has been linked to a new work item: W-9298084 |
is fixed. |
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:
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
The text was updated successfully, but these errors were encountered: