-
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
.forceignore ignores configuration #2737
Comments
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. |
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 |
@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. |
@iowillhoit I am facing the same or a very similar issue: Given the following
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 |
I've reproduced what you guys are seeing. However, things are working as designed. This is due to the timing of when the During a deployment, the rules are applied to a Profile with a file name of So the solution is to find a rule that will satisfy both file name formats. For the admin profile case, that rule would be: Based on this, closing this issue. |
@shetzel Oh wow, that is an eye opener! Thank you so much for this explanation. 🙏 |
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 |
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. |
This issue has been linked to a new work item: W-15303749 |
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. |
This issue is fixed in version 2.40.7 (May 8, 2024) of the CLI. Enjoy! |
Summary
Probably linked to #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
: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
Additional information
#N/A
The text was updated successfully, but these errors were encountered: