force:source:deploy -x package.xml: ListView are always all deployed

[nvuillam]

Summary

I do NOT want to deploy ListViews, and whereas the type is empty in my package.xml, they are all deployed with their parent object...

Steps To Reproduce:

Create a package.xml file containing an CustomObject, and empty ListView type (or no ListView type, the result is the same)

<?xml version="1.0" encoding="UTF-8" ?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account</members>
        <name>CustomObject</name>
    </types>
    <types>
        <name>ListView</name>
    </types>
</Package>

call sfdx force:source:deploy -x package.xml

Expected result

ListViews not deployed, existing ones in target org remain the same

Actual result

ListViews are deployed whereas they should not , so target org ListViews are overidden

Log sample:

Account.ComptesFelix                                                         ListView                  force-app\main\default\objects\Account\listViews\ComptesFelix.listView-meta.xml
Account.Fournisseurs                                                         ListView                  force-app\main\default\objects\Account\listViews\Fournisseurs.listView-meta.xml
Account.MesComptes                                                           ListView                  force-app\main\default\objects\Account\listViews\MesComptes.listView-meta.xml

System Information

{
        "cliVersion": "sfdx-cli/7.132.0",
        "architecture": "win32-x64",
        "nodeVersion": "node-v14.18.0",
        "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/analytics 0.30.0",
                "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
                "@salesforce/sfdx-scanner 2.5.1",
                "alias 1.2.0 (core)",
                "apex 0.7.0 (core)",
                "auth 1.8.0 (core)",
                "config 1.3.2 (core)",
                "custom-metadata 1.0.12 (core)",
                "data 0.6.6 (core)",
                "generator 1.2.1 (core)",
                "info 1.1.4 (core)",
                "lightning-flow-scanner 0.0.5",
                "limits 1.3.0 (core)",
                "org 1.11.0 (core)",
                "salesforce-alm 53.7.0 (core)",
                "schema 1.1.0 (core)",
                "sfdmu 4.11.9",
                "sfdx-cli 7.132.0 (core)",
                "sfdx-essentials 2.12.0 (link) D:\\git\\sfdx-essentials",
                "sfdx-git-delta 4.12.0",
                "sfdx-hardis 2.64.0 (link) D:\\git\\sfdx-hardis",
                "sfpowerkit 4.0.1",
                "shane-sfdx-plugins 4.43.0",
                "├─ @mshanemc/sfdx-sosl 1.1.0",
                "└─ @mshanemc/plugin-streaming 1.1.7",
                "source 1.6.2 (core)",
                "telemetry 1.4.0 (core)",
                "templates 52.7.0 (core)",
                "texei-sfdx-plugin 1.14.0",
                "trust 1.1.0 (core)",
                "user 1.7.0 (core)"
        ],
        "osVersion": "Windows_NT 10.0.19044"
}

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.

[WillieRuemmele]

Hi @nvuillam have you explored adding ListViews to the .forceignore file? that should prevent ListViews from being deployed

[nvuillam]

@WillieRuemmele it may work, but my requirement is to deploy some of them, and to push them in scratch orgs, so I need to package.xml way to work :/

[WillieRuemmele]

are you using both source:deploy and source:push together? Running a deploy after a push will ruin the source-tracking files required for push to work correctly. It is recommended to stick to using only deploy or push.

I would recommend exploring the .forceignore direction. It may require you editing that file for different commands to get different results

[nvuillam]

No, I know that source:pull / pull are for scratch orgs / sandboxes with tracking ^^

My requirement is to be able to deploy (via CI) to a production org a restricted list of sources (described in my package.xml), with a finer granularity level than the whole metadata .object big XML.

Basically, when the metadata folder is created under the hook by force:source:deploy before being deployed, it should not include the ListViews that are not part of my package.xml ( same way than for CustomField for example: having something in packageXml CustomObject should just bring .object-meta.xml sfdx-source, not the content of sfdx sub-folders)

The problem is that undepending the content of ListView members in my package.xml, it always puts all the listviews of an object :/

[WillieRuemmele]

ok, I understand a little better now, thank you for explaining. Unfortunately this sounds more like a limitation of the metadata API, rather than a bug in the CLI. I still believe that using the .forceignore file will lead to the best results, but I'm sure there are a lot more knowledgeable people than me online who might have a better solution.

I'm closing this issue for now. If you believe this is a bug with the CLI feel free to reopen it.

[nvuillam]

@WillieRuemmele why could force:source:deploy deploy only one custom field on a CustomObject, and not only one ListView ? I don't have the rights to reopen, pleas can you do it ? Thanks :)

[WillieRuemmele]

If you're only trying to deploy certain ListViews you can specify them in your package like

<types>
    <members>Account.My_List_View</members>
    <name>ListView</name>
</types>

[nvuillam]

Thanks, but ... I also want to deploy CustomObjects , but not all their subfolders (like for CustomField) ( this is a full deployment to production org)

[maggiben]

Hi, have you tried to use .forceignore on those subfolders ?

[nvuillam]

Hi, have you tried to use .forceignore on those subfolders ?

No, because i know from package.xml than I need to deploy object A with ListViews A1,A2 and A4 (and not A3 which is not in my package.xml)

This package.xml is dynamically generated from CI, and the use case is to not overwrite a ListView that is already existing in target org

I basically just need force:source:deploy -x package.xml to ... not deploy items that are not in this package.xml, i'd love someone to fix this actual bug ❤️

[maggiben]

I confirm that deploying a CustomObject also deploys it's custom fields: I logged a new story W-10384508 it should be prioritised soon.

*NOTE: I did not marked the issue as a bug yet because since this is been the behaviour for a long time I want to run this though the board and consult the experts if this is an expected result or not and what we can do about it.

[nvuillam]

Many thanks @maggiben :) I have some clients who will love to have such debug/enhancement (whatever we call it :) )

[mkreth]

Great to see that this is being looked into - I'd be curious to hear what the experts think. As this has been in place for so long - e.g. that CustomObject is a container that when deployed will include its children automatically - a change would affect a lot of people. I'd expect a very clear announcement or maybe something like an opt-in to any new behaviour.

[tggagne]

This has got to be a bug. The ant migration tool could limit itself to only what was in the package.xml file. It had the extra feature of deploying even /less/ than what was in the package file by deploying only the sources in a .zip file (as long as the files in the zip file were in the package file).

If sfdx can't provide the same amount of control as the ant migration tool, how will developers be able to embrace it without falling back to ant?

I'm having an issue right now that no matter whether I remove listviews from my package.xml, ALL the listviews keep showing back up.

[lqor]

I run today into this issue. Not that it is a super urgent, but an annoying issue for sure

[nvuillam]

Still triggering issues at Cloudity... any chance we have a fix someday ?