(7.158.1) sfdx deploy and retrieve with package.xml will fail if at least one item is in the .forceignore.

[gcidre1]

Summary

As stated in the title for sfdx-cli/7.158.1, the following commands will fail: sfdx force:source:deploy -x manifest/package.xml sfdx force:source:retrieve -x manifest/package.xml

if one of its items is in .forceignore file.

Steps To Reproduce:

Create metadata. Add metadata to the package.xml run any of the command listed in the summary.

NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

1. This is step 1.
2. This is step 2. All steps should start with '1.'

Expected result

I would expect it to go through or at least get a warning/information about it like when doing sfdx force:source:deploy/retrieve -p option.

Actual result

Throws error saying it is listed in the package.xml but not in the unpackaged zip file.

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.) Using gitbash on windows
• If you are using sfdx
  • Run sfdx version --verbose --json
• If you are using sf
  • Run sf version AND sf plugins --core sfdx version --verbose --json { "cliVersion": "sfdx-cli/7.158.1", "architecture": "win32-x64", "nodeVersion": "node-v16.15.1", "pluginVersions": [ "@oclif/plugin-autocomplete 0.3.0 (core)", "@oclif/plugin-commands 1.3.0 (core)", "@oclif/plugin-help 3.3.1 (core)", "@oclif/plugin-not-found 1.2.6 (core)", "@oclif/plugin-plugins 1.10.11 (core)", "@oclif/plugin-update 1.5.0 (core)", "@oclif/plugin-warn-if-update-available 1.7.3 (core)", "@oclif/plugin-which 1.0.4 (core)", "@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)", "alias 2.1.0 (core)", "apex 0.13.0 (core)", "auth 2.2.2 (core)", "community 2.0.0 (core)", "config 1.4.12 (core)", "custom-metadata 2.0.0 (core)", "data 2.0.4 (core)", "generator 2.0.2 (core)", "info 2.0.1 (core)", "limits 2.0.1 (core)", "org 2.0.1 (core)", "salesforce-alm 54.6.2 (core)", "schema 2.1.1 (core)", "sfdx-cli 7.158.1 (core)", "signups 1.2.0 (core)", "source 2.0.3 (core)", "telemetry 2.0.0 (core)", "templates 55.0.0 (core)", "trust 2.0.1 (core)", "user 2.1.0 (core)" ], "osVersion": "Windows_NT 10.0.19042" }

Additional information

Feel free to attach a screenshot.

[github-actions[bot]]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[gcidre1]

I'll admit I don't know if deploying/retrieving package.xml should behave like that. If it is, maybe I can change this to a feature where you can put a flag to treat as warning

[gcidre1]

For retrieve, I get this error: Metadata API request failed: ApexPage metadata types require source files, but unpackaged\pages\MicrobatchSelfReg.page is forceignored.

That listed in the package.xml but not in the unpackaged zip file error happens with deploy.

[mdonnalley]

@gcidre1 thanks for filing an issue.

Looking at the information you provided, I believe that the deploy and retrieve commands are working as expected. The most likely reason for the errors is that you're ignoring a file that's required to have valid metadata (e.g. one piece of metadata depends on metadata that's being ignored by .forceignore)

[gcidre1]

I see. I guess thanks for the help. The deploy one must be a new thing since the 7.85.1 version deploys just fine but not this version.