forceignore file does not respect ignoring of profiles

[ImJohnMDaniel]

Summary

force:source:pull pulls profiles from scratch org to codebase regardless of whether or not profiles are ignored in the .forceignore file

Steps To Reproduce:

Repository to reproduce: profile-ignore-test

-- Use repo's README.md file for reproduction steps

Expected result

profiles should not be pulled down to project source code if profiles are ignored in .forceignore

Actual result

profiles are being pulled down

System Information

{
        "cliVersion": "sfdx-cli/7.145.0",
        "architecture": "darwin-x64",
        "nodeVersion": "node-v16.14.2",
        "pluginVersions": [
                "@dx-cli-toolbox/sfdx-toolbox-package-utils 0.8.4 (link) /Users/john/workspace/_cli-related/sfdx-toolbox-package-utils",
                "@dx-cli-toolbox/sfdx-toolbox-utils 0.0.2 (link) /Users/john/workspace/_cli-related/sfdx-toolbox-utils",
                "@oclif/plugin-autocomplete 1.2.0",
                "@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 0.1.7 (core)",
                "@salesforce/sfdx-scanner 2.13.1",
                "alias 2.0.0 (core)",
                "apex 0.11.0 (core)",
                "auth 1.8.2 (core)",
                "community 1.1.4 (core)",
                "config 1.3.24 (core)",
                "custom-metadata 1.0.12 (core)",
                "data 0.6.12 (core)",
                "generator 1.2.2 (core)",
                "info 1.3.1 (core)",
                "limits 1.3.0 (core)",
                "org 1.11.2 (core)",
                "salesforce-alm 54.1.0 (core)",
                "schema 1.1.0 (core)",
                "sfdmu 4.13.0",
                "sfdx-cli 7.145.0 (core)",
                "shane-sfdx-plugins 4.43.0",
                "├─ @mshanemc/plugin-streaming 1.1.7",
                "└─ @mshanemc/sfdx-sosl 1.1.0",
                "soqlx-opener 0.1.12",
                "source 1.9.2 (core)",
                "telemetry 1.4.0 (core)",
                "templates 54.3.0 (core)",
                "trust 1.1.0 (core)",
                "user 1.7.1 (core)"
        ],
        "osVersion": "Darwin 21.4.0"
}

Additional information

n/a

[github-actions]

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.

[aheber]

@ImJohnMDaniel, not sure if this is helpful but I just finished tuning my Profile management with my .forceignore file.

# ignore pulled/retrieved profiles, still allowing deployment from source
**/profiles/*
!force-app/**/main/default/profiles/*

**/profiles/* was needed to block retrieve/pull of profiles from the org, even if they are changed. I believe when retrieving the .forceignore is actually applied to the MDT formatted paths, not applied against the final resulting path once unpacked and copied. (that is probably the bug that you're representing)

The trick in this is to not-ignore the profiles that I currently have in source because I do want them deployed but I never want to see them changed by something like modifying the object schemas. We've only had this in place for a few weeks but so far we've been really happy with the results. No more errant profile changes while still being able to populate them into Scratch Orgs during build.

I realize there is a difference between opening an issue because you found a bug and because you need a solution, hopefully this sheds some light on either.

[ImJohnMDaniel]

@aheber thanks for the input. I understand what you are saying even though not directly related

[ImJohnMDaniel]

@mshanemc and others on the Salesforce CLI Team -- I guess my question would be to start with, is the way that I listed the entry in the .forceignore file still valid considering the recent update to the way that force:source:* commands work?

[mshanemc]

Was this working before?
**.profile-meta.xml

This definitely works
*/profiles/

tip: you can force:source:ignored to get an output of how .forceignore is matching local files.
I get a hit from *.profile-meta.xml but not **.profile-meta.xml

Also, code here if you wanna play with it https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/resolve/forceIgnore.ts

It's using https://github.com/kaelzhang/node-ignore

[ImJohnMDaniel]

@mshanemc

Was this working before?
**.profile-meta.xml

Yes, it was.

If I have to guess, I would say that it broke with the recent switch to the new force:source commands -- but that is only a guess.

Having said that, I tried some variations using your suggestion of force:source:ignored:list and I was able to find that this combination works

**/*.profile-meta.xml

For my needs, I can proceed with that pattern.

Also, after experimenting a bit, it would appear that this issue is not restricted to just profiles. It would appear that any pattern of "double asterisks and then a period" ( **. ) is impacted here. I just tried another ignore pattern we sometimes use which is **.settings-meta.xml and that too is no longer working. If I change the pattern to **/*.settings-meta.xml, then the force:source:ignored:list command shows that it match that pattern.

I will defer to you regarding whether or not to keep this issue open.

[mshanemc]

I think it's working like it's supposed to and **/*.profile-meta.xml looks way more normal to me.

But, if **.foo is supported for gitignore, we want to match that behavior.

[mshanemc]

we did intentionally drop our custom implementation of ignore files because that's a dumb thing to implement, but that was quite some time ago.

[ImJohnMDaniel]

It could have very well been a nuance of the custom implementation and I am only just now catching the behavior change. But I am good at this point, so completely your discretion if you want to pursue this further.

[ImJohnMDaniel]

@mshanemc, I may have spoken too soon. This issue is still present.

I have a simple project. I have tried the following combinations of entries in the forceignore file:

• **/*.profile-meta.xml
• *.profile-meta.xml
• Admin.profile-meta.xml

In each case, I create the scratch org, push a handful of files to that scratch org, then execute a force:source:pull and sure enough, the Admin profile metadata file is getting created in the default area.

[mshanemc]

can it be replicated with https://github.com/ImJohnMDaniel/profile-ignore-test?

[uip-robot-zz]

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

[shetzel]

I just replicated it with John's profile-ignore-test project. I wonder if the output from status below has a clue.

This was using the **/*.profile-meta.xml entry in forceignore.

[iowillhoit]

This fix is included in the latest stable build of sfdx (7.149.1). Let us know if you still are having issues. Thanks!

[Windyo]

Edit : migrated to new issue #2737