sf 1.82 (June 14, 2023) no longer consolidates sources from multiple directories during deploy

[jeffreyazevedo]

Summary

Starting with sf 1.82, if you're pushing disparate source files that live in different directories, only one of the files "wins out" and is deployed to the org. Prior to 1.82, it seems that the combination of the two files would be deployed to the org.

Steps To Reproduce:

Repository to reproduce: jeffreyazevedo/sf-cli-multi-directory

This simple repo contains two Opportunity stage standard value set metadata files in two different directories. One includes a value of Test Stage 1 and the other a value of Test Stage 2. Both directories are defined as packageDirectories in the sfdx-project.json file.

1. Generate a scratch org and deploy the project using sf project deploy start
2. Log into the org and navigate to the Opportunity Stage field in setup

Expected result

Both Test Stage 1 and Test Stage 2 should be present as Opportunity Stages Picklist Values. This is true when deploying with sf version 1.81.

Actual result

When using sf version 1.82, only Test Stage 2 is present in the org after deployment.

System Information

CLI Version:
@salesforce/cli/1.82.6

Architecture:
win32-x64

Node Version:
node-v18.16.0

Plugin Version:
@dx-cli-toolbox/sfdx-toolbox-package-utils 0.8.4 (user)
@oclif/plugin-autocomplete 2.3.0 (core)
@oclif/plugin-commands 2.2.15 (core)
@oclif/plugin-help 5.2.9 (core)
@oclif/plugin-not-found 2.3.24 (core)
@oclif/plugin-plugins 3.1.2 (core)
@oclif/plugin-search 0.0.17 (core)
@oclif/plugin-update 3.1.17 (core)
@oclif/plugin-version 1.3.4 (core)
@oclif/plugin-warn-if-update-available 2.0.37 (core)
@oclif/plugin-which 2.2.22 (core)
@salesforce/cli 1.82.6 (core)
apex 2.3.2 (core)
auth 2.8.1 (core)
data 2.3.22 (core)
deploy-retrieve 1.11.4 (core)
info 2.6.19 (core)
limits 2.3.18 (core)
login 1.2.11 (core)
org 2.9.7 (core)
schema 2.3.12 (core)
settings 1.4.10 (core)
sobject 0.1.23 (core)
source 2.10.13 (core)
telemetry 2.2.0 (core)
templates 55.4.20 (core)
trust 2.4.20 (core)
user 2.3.16 (core)
sfdmu 4.28.0 (user)

OS and Version:
Windows_NT 10.0.22621

Shell:
cmd.exe

Root Path:
C:\Users\Jeffrey Azevedo\AppData\Local\sf\client\1.82.6-35a6434

PS C:\PMDev\MultiDirectoryDeploy> sf version --verbose --json
{
"cliVersion": "@salesforce/cli/1.82.6",
"architecture": "win32-x64",
"nodeVersion": "node-v18.16.0",
"osVersion": "Windows_NT 10.0.22621",
"shell": "cmd.exe",
"rootPath": "C:\Users\Jeffrey Azevedo\AppData\Local\sf\client\1.82.6-35a6434",
"pluginVersions": [
"@dx-cli-toolbox/sfdx-toolbox-package-utils 0.8.4 (user)",
"@oclif/plugin-autocomplete 2.3.0 (core)",
"@oclif/plugin-commands 2.2.15 (core)",
"@oclif/plugin-help 5.2.9 (core)",
"@oclif/plugin-not-found 2.3.24 (core)",
"@oclif/plugin-plugins 3.1.2 (core)",
"@oclif/plugin-search 0.0.17 (core)",
"@oclif/plugin-update 3.1.17 (core)",
"@oclif/plugin-version 1.3.4 (core)",
"@oclif/plugin-warn-if-update-available 2.0.37 (core)",
"@oclif/plugin-which 2.2.22 (core)",
"@salesforce/cli 1.82.6 (core)",
"apex 2.3.2 (core)",
"auth 2.8.1 (core)",
"data 2.3.22 (core)",
"deploy-retrieve 1.11.4 (core)",
"info 2.6.19 (core)",
"limits 2.3.18 (core)",
"login 1.2.11 (core)",
"org 2.9.7 (core)",
"schema 2.3.12 (core)",
"settings 1.4.10 (core)",
"sobject 0.1.23 (core)",
"source 2.10.13 (core)",
"telemetry 2.2.0 (core)",
"templates 55.4.20 (core)",
"trust 2.4.20 (core)",
"user 2.3.16 (core)",
"sfdmu 4.28.0 (user)"
]
}

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

[mshanemc]

@jeffreyazevedo is the behavior limited to that particular metadata (standardValueSet) or is it happening on other types?

[jeffreyazevedo]

I gave the same thing a try for a settings file (Chatter.settings) with each enabling a different chatter setting (emoticons and out of office) and similarly only one of the settings was ultimately enabled. However this behavior seems to be the same on 1.81 and 1.82, so not a regression. (I've committed this new file to the existing repo in case that's helpful.)

However I would expect any metadata that isn't monolithic in nature (like standardValueSet, settings, profiles, permission sets, etc) to end up fully applied even if there are multiple files. Obviously if two files contradict each other (one grants a certain permission and the other takes the same permission away), then one of them has to win out. But if the two files have no overlap and would each be successfully applied if deployed individually in separate deployments, then it should follow that the same thing happens when done together in a single sf project deploy start. The output of the command even seems to imply that both files were deployed, but that's not accurate. And there's no way to tell which one was ignored and which one was actually deployed.

PS C:\PMDev\MultiDirectoryDeploy> sf project deploy start
Deploying v57.0 metadata to test-gazl6uzr1jkh@example.com using the v58.0 SOAP API.
Deploy ID: 0AfDC00000d9Mfs0AE
Status: Succeeded | ████████████████████████████████████████ | 2/2 Components

Deployed Source
================================================================================================================================
| State   Name             Type             Path
| ─────── ──────────────── ──────────────── ────────────────────────────────────────────────────────────────────────────────────
| Changed Chatter          Settings         force-app\main\default\settings\Chatter.settings-meta.xml
| Changed Chatter          Settings         unpackaged\main\default\settings\Chatter.settings-meta.xml
| Changed OpportunityStage StandardValueSet force-app\main\default\standardValueSets\OpportunityStage.standardValueSet-meta.xml
| Changed OpportunityStage StandardValueSet unpackaged\main\default\standardValueSets\OpportunityStage.standardValueSet-meta.xml

[git2gus]

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

[mshanemc]

Great repro! I've figured out what caused this (swapping out a library). Thanks for testing with RC and for reporting.

[mshanemc]

I'm going to share what I've learned so far--no solution yet, but I can explain the problem. It's...crazy.

Background

all the deploy commands (source:push, source:deploy, mdapi:deploy, project:deploy) use https://github.com/forcedotcom/source-deploy-retrieve which until recently used archiver to make zip files. It's got various bugs, one of which caused #2125.

So we swapped it for https://github.com/Stuk/jszip (also heavily used generally, and used in other areas of the CLI, like when we zip up stuff for packaging).

Investigation

I logged what Archiver (the old way) was doing. It adds the same file to the zip twice

adding to zip package.xml
adding to zip standardValueSets/OpportunityStage.standardValueSet
adding to zip standardValueSets/OpportunityStage.standardValueSet

And you may be thinking, "wait, you can put the same filename in a zip twice?!" Well, Archiver does. 🤪

And I also wrote out the zip file to the file system to confirm this:

➜  sf-cli-multi-directory git:(main) ✗ zip -sf zipToSend.zip 
Archive contains:
  package.xml
  standardValueSets/OpportunityStage.standardValueSet
  standardValueSets/OpportunityStage.standardValueSet
Total 3 entries (1079 bytes)

Note: there is no folder you could create on your filesystem in mdapi format and then zip to arrive at such a zip file. It only exists because of what I'd consider "another bug in Archiver".

Even when I unzip that abomination, I only get one OpportunityStage file because, you know, two files can't exist at the same place on the FileSystem.

It also means the metadata API isn't unzipping to a FS and then processing the files, it's iterating/streaming them out of the zip folder or something.

---

jsZip maintains the "in progress zip files" with keys like this, so the second file you give it with the same name is a modification (js objects don't allow duplicate keys).

{
      "standardValueSets/OpportunityStage.standardValueSet": {...}
} 

So the new library (sanely) doesn't allow duplicate paths in the zip.

---

OK, so don't duplicate the files! Unfortunately, they have to be named exactly
standardValueSets/OpportunityStage.standardValueSet. Mdapi format (what's in the zip file that we send to the API) doesn't allow nested folders for this type.

Things that won't work

• standardValueSets/OpportunityStage.standardValueSet
• x/standardValueSets/OpportunityStage.standardValueSet.
• standardValueSets/x/OpportunityStage.standardValueSet.