cli Some metadata do not deploy on profiles if more than one file per profile exists

Summary

sf project deploy start doesn't deploy metadata when more than 1 profile file exists.

Steps To Reproduce

Repository to reproduce sfProfileIssues

Create new scratch org
Run sf project deploy start to deploy 3 layouts and System Admin profile that contains only layout assignment.
Note that deployment was successful but Account layout assignment didnt change on scratch org.

Expected result

Layout assignment for Admin profile should change to Account-A

Actual result

Layout assignment for Admin profile do not change at all

Additional information

Looks like similar issue to https://github.com/forcedotcom/cli/issues/2230

System Information

CLI:
@salesforce/cli/2.73.9 win32-x64 node-v18.16.0

Plugin Version:
@oclif/plugin-autocomplete 3.2.17 (core)
@oclif/plugin-commands 4.1.16 (core)
@oclif/plugin-help 6.2.21 (core)
@oclif/plugin-not-found 3.2.35 (core)
@oclif/plugin-plugins 5.4.25 (core)
@oclif/plugin-search 1.2.18 (core)
@oclif/plugin-update 4.6.23 (core)
@oclif/plugin-version 2.2.20 (core)
@oclif/plugin-warn-if-update-available 3.1.30 (core)
@oclif/plugin-which 3.2.25 (core)
@salesforce/cli 2.73.9 (core)
apex 3.6.8 (core)
api 1.3.3 (core)
auth 3.6.87 (core)
community 3.0.2 (user)
custom-metadata 3.0.3 (user)
data 4.0.1 (core)
deploy-retrieve 3.17.7 (core)
info 3.4.32 (core)
limits 3.3.44 (core)
marketplace 1.3.7 (core)
org 5.2.23 (core)
packaging 1.27.2 (user)
schema 3.3.46 (core)
settings 2.4.10 (core)
signups 1.4.13 (user)
sobject 1.4.49 (core)
telemetry 3.6.29 (core)
templates 56.3.35 (core)
trust 3.7.55 (core)
user 3.6.6 (core)
@salesforce/sfdx-scanner 3.18.0 (user)
aura-helper-sfdx 1.2.2 (user)

SF ENV. VARS.
SF_AUTOUPDATE_DISABLE,true
SF_DISABLE_AUTOUPDATE,true
SF_UPDATE_INSTRUCTIONS,Use "npm update --global @salesforce/cli" to update npm-based installations.

Windows: true
Shell: C:\Users\mlipinski\AppData\Local\Programs\Git\usr\bin\bash.exe
Channel: stable

Diagnostics

:white_check_mark: pass - salesforcedx plugin isn’t installed :white_check_mark: pass - you don't have any linked plugins :white_check_mark: pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org :white_check_mark: pass - [@salesforce/plugin-trust] can ping: https://registry.yarnpkg.com :white_check_mark: pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org/ :white_check_mark: pass - using latest or latest-rc CLI version :white_check_mark: pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion :white_check_mark: pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches default target org max apiVersion :white_check_mark: pass - can access: https://test.salesforce.com :white_check_mark: pass - can access: https://appexchange.salesforce.com/services/data :white_check_mark: pass - can access: https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-win32-x64-buildmanifest :x: fail - [@salesforce/plugin-auth] CLI supports v2 crypto :white_check_mark: pass - [@salesforce/plugin-auth] CLI using stable v1 crypto

Jan 28 '25 13:01 mlipinski307

This seems to be a bug with the CLI, when we set SF_MDAPI_TEMP_DIR and inspect the generated MD it's sending to the server, the Admin profile never has the LayoutAssignment tag populated, I tried moving the order of listed packages in sfdx-project.json, but that had no affect, removing force-app2 entirely from the list, generated the correct profile to deploy. I'm not sure why it's only using the force-app2 profile.

running the command like sf project deploy start --source-dir force-app2 --source-dir force-app with the flags in that order, will preserve the correct Admin Profile.

Once that deploy works, you may need to run sf project reset tracking to get the source tracking information caught up

Jan 29 '25 17:01 WillieRuemmele

Hi @WillieRuemmele

Please note that the repository that I shared was just the basic example of that issue. Proposed workaround sf project deploy start --source-dir force-app2 --source-dir force-app works only because one of the profile files is empty. This is not real project scenario. We wouldn't store empty System Administrator profile in repository just for a sake of it, it contains metadata.

Running sf project deploy start --source-dir force-app --source-dir force-app2 results in incorrect deployment.

Profile files are still incorrectly merged for deployment. https://github.com/mlipinski307/sfProfileIssue/tree/example1 - adds 2 Record Types and assignment of them, spited into 2 profile files that is not fully deployed.

Jan 31 '25 11:01 mlipinski307

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

Jan 31 '25 15:01 git2gus[bot]