sf project retrieve retrieves fields ignored in .forceignore in profiles

Question

W want to periodically retrieve whole production org, except for some things, that we want to ignore.

Up until now it worked fine using .forceignore. But few days ago it stopped when the thing to ignore became a field on a Contact.

**/objects/Contact/fields/BuyerAttributes.field-meta.xml prevents field from getting retrieved, but profiles still contain the entry for ignored field.

Is this expected behaviour or should we start to look for another solution than .forceignore.

Example: Contents of the package.xml file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Contact</members>
        <name>CustomObject</name>
    </types>
    <types>
        <members>Admin</members>
        <name>Profile</name>
    </types>
    <version>60.0</version>
</Package>

Contents of the .forceignore file:

**/objects/Contact/fields/BuyerAttributes.field-meta.xml

Command executed:

sf project retrieve start -x '<path-to-package-file>/package.xml'

Expected behaviour: Profile does not include node for BuyerAttributes.

Actual behaviour: It does.

Answer 1

I believe this is expected behavior.

sf project retrieve is just looking at the name of the metadata (and the contents of .forceignore) to determine what to retrieve.

Outside of some basic processing to translate between Metadata API form where, for example, the fields are part of the CustomObject metadata; and Source form, where SObject fields are their own, individual metadata files under the directory structure for the corresponding CustomObject, the SF CLI doesn't touch/alter the metadata.

I get the feeling that on deployment, most metadata is handled with a straight "replace the entirety of what we currently have with this thing we've been given". The main exception to that being CustomField, where fields that aren't mentioned are simply not touched.

Profiles have been historically difficult/impossible to deploy changes to. If you were to somehow remove an individual field from profiles, I'd expect one of two things to happen:

• Salesforce complains when you try to deploy, because there's a discrepancy between the fields contained in the Profile and the fields contained in the CustomObject
• Salesforce allows you to deploy, but the permission for that CustomField gets completely wiped out. Similar to deploying a field to a different org, nobody, not even System Administrators, has any access to that field. Queries and code that reference that field would experience runtime failures (even outside of the code in the project that you're ignoring that field in).