.forceignore ignores configuration

[Windyo]

Summary

Probably linked to https://github.com/forcedotcom/cli/issues/1471

Both Profiles and PermissionSets seem resistant to .forceignore. Setting specific exclusions simply don't work despite the CLI claiming the exclusions work.

Steps To Reproduce

example line: **/permissionsets/Sales_User.permissionset-meta.xml

output of sf project list ignored : Found the following ignored files: force-app\main\default\aura.eslintrc.json force-app\main\default\lwc.eslintrc.json force-app\main\default\permissionsets\Sales_User.permissionset-meta.xml

output of sf project retrieve start --target-org MyOrg --ignore-conflicts -m PermissionSet:

==================================================================================================================================================================
| State   Name                                    Type               Path
| ─────── ─────────────────────────────────────── ────────────────── ─────────────────────────────────────────────────────────────────────────────────────────────
| Changed Sales_User                           PermissionSet      force-app\main\default\permissionsets\Sales_User.permissionset-meta.xml

Expected result

The permissionset doesn't get pulled

Actual result

It gets pulled

System Information

@salesforce/cli/2.28.6 win32-x64 node-v20.11.0 on cmder on windows64

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.28.6",
  "nodeVersion": "node-v20.11.0",
  "osVersion": "Windows_NT 10.0.19045",
  "rootPath": "C:\\Users\\Geoffrey\\AppData\\Local\\sf\\client\\2.28.6-cb38ecf",
  "shell": "cmd.exe",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.7 (core)",
    "@oclif/plugin-commands 3.1.2 (core)",
    "@oclif/plugin-help 6.0.12 (core)",
    "@oclif/plugin-not-found 3.0.10 (core)",
    "@oclif/plugin-plugins 4.2.1 (core)",
    "@oclif/plugin-search 1.0.13 (core)",
    "@oclif/plugin-update 4.1.10 (core)",
    "@oclif/plugin-version 2.0.12 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.10 (core)",
    "@oclif/plugin-which 3.0.15 (core)",
    "@salesforce/cli 2.28.6 (core)",
    "apex 3.0.22 (core)",
    "auth 3.3.11 (core)",
    "custom-metadata 3.1.9 (user)",
    "data 3.0.19 (core)",
    "deploy-retrieve 3.2.11 (core)",
    "info 3.0.21 (core)",
    "limits 3.1.7 (core)",
    "marketplace 1.0.20 (core)",
    "org 3.3.11 (core)",
    "packaging 2.1.6 (core)",
    "schema 3.1.1 (core)",
    "settings 2.0.22 (core)",
    "sobject 1.1.9 (core)",
    "source 3.1.10 (core)",
    "telemetry 3.1.11 (core)",
    "templates 56.0.13 (core)",
    "trust 3.3.6 (core)",
    "user 3.2.7 (core)",
    "@salesforce/sfdx-scanner 3.21.0 (user)",
    "bbdoc 4.1.0 (user)",
    "sfdmu 4.32.2 (user)",
    "sfdx-git-delta 5.34.0 (user)"
  ]
}

Additional information

#N/A

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

[iowillhoit]

Hello @Windyo, I am not able to replicate this. I used the same version of the CLI (although on a Mac) At first I thought this might be an encoding issue with the _ in the PermissionSet name, but that does not seem to matter. Could you put together a repo to reproduce this issue?

[Windyo]

@iowillhoit sorry for the delay - crunch time on a project. Will try to repro on a non-client repo in a month or so and update then.

[amtrack]

@iowillhoit I am facing the same or a very similar issue:

Given the following .forceignore file

**/Admin.profile-meta.xml

Retrieving the Admin Profile (which should be present in any org)

$ sf project retrieve start -m "Profile:Admin"
Retrieving v60.0 metadata from xxx using the v60.0 SOAP API
Preparing retrieve request... Succeeded
Warning: Nothing retrieved

The output says "Nothing retrieved", but the Profile was retrieved indeed:

$ tree force-app
force-app
└── main
    └── default
        └── profiles
            └── Admin.profile-meta.xml

---

I've created a Minimal Reproduction Example: https://github.com/mdapi-issues/mre-forceignore-retrieve-command It has a video and also a GitHub Action to prove it's not an issue with my machine. Further this doesn't only seem to be limited to Profile and PermissionSet. I also reproduced it for e.g. StandardValueSet.

[shetzel]

I've reproduced what you guys are seeing. However, things are working as designed. This is due to the timing of when the .forceignore rules are applied and the 2 different file and file naming formats for mdapi and source.

During a deployment, the rules are applied to a Profile with a file name of Admin.profile-meta.xml so a rule of **/Admin.profile-meta.xml in .forceignore would work just fine in that case. The profile would not deploy. The same thing applies to the sf project list ignored command. The rule matches the source format of the file name for the admin profile. During a retrieval, the rules are applied to metadata in mdapi format because that's how they are sent from the server. That file name is Admin.profile and does not match the rule in .forceignore so the conversion from mdapi to source format proceeds and the file is written to the proper location.

So the solution is to find a rule that will satisfy both file name formats. For the admin profile case, that rule would be: **/Admin.profile*. I've verified that this works.

Based on this, closing this issue.

[amtrack]

@shetzel Oh wow, that is an eye opener! Thank you so much for this explanation. 🙏

[Windyo]

Thank you for the explanation :)

For transparency though, I disagree with the fact that this issue should be "closed" - it is not the responsibility of a Developer or any other sort of CLI user to know the internal names of things, nor is it their responsibility to interpret a tool saying "yes I work fine" as "Actually it won't work as you intend".

It is my opinion that this should be flagged as a bug, and that the matching should be done against Source format - or at the very list, that sf project list ignored should appropriately check against the Server what will be ignored instead of showing things that will most definitely not be ignored on fetch.

[jongpie]

I completely agree with @Windyo - this feels like it should be treated as a bug (and kept open). In modern Salesforce projects, only the source metadata format is used, so it's natural/expected that people want to ignore certain things based on the filenames used by the source format. Having to also exclude based on the older MDAPI format isn't intuitive at all, and feels like an implementation detail that the CLI should handle.

[git2gus[bot]]

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

[shetzel]

Thanks for the feedback. Based on this and some team discussion we agree that it is not working as it should so we'll fix and update the docs to make it clear.

The fix will be to make .forceignore work consistently whether source format or mdapi format files are involved. E.g., if deploying/retrieving source format it will respect file names of .forceignore entries in that format. Deploying/retrieving mdapi format will respect file names of .forceignore entries in that format.