CustomLabel String replacement not working correctly with --manifest flag #2755
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. |
github-actions
bot
added
the
validated
cnwork
changed the title
|
Excellent repro steps! Makes it so much easier to understand the problem. Thank you! If you compare the manifests that are actually generated by those 2 commands (use the I modified So there is at least a good workaround. However, this seems like it could be improved. I tried this command: |
shetzel
added
bug
|
This issue has been linked to a new work item: W-15262083 |
|
Thanks a lot @shetzel ! Yes, that workaround does indeed get the desired behavior. However, I'm glad that a fix is being worked on. We are using this in a CI pipeline and currently I would have to do some script gymnastics to add the CustomLabel type inside the package.xml. Not a biggie but if a fix is in the works, we can deal with it until it's released. We don't deploy CustomLabels every day. I appreciate the help! Thanks! |
|
@cnwork - should make it into the CLI release candidate tomorrow. |
|
This issue is fixed in version 2.34.6 of Salesforce CLI. |
Summary
When using the
sf project deploy start --manifest package.xml, custom labels inside the package.xml will not get replaced.However when using
sf project deploy start --source-dir changed-sources, the custom labels inside the folder do get replaced.Steps To Reproduce
Repo: Forked dreamhouse-lwc
Use git-delta tool to generate the delta between the last two commits:
This should generate the following file structure:
changed-sources/ ├── destructiveChanges │ ├── destructiveChanges.xml │ └── package.xml ├── force-app │ └── main │ └── default │ ├── classes │ │ ├── MyClass.cls │ │ ├── MyClass.cls-meta.xml │ │ ├── MyClassTest.cls │ │ └── MyClassTest.cls-meta.xml │ └── labels │ └── CustomLabels.labels-meta.xml └── package └── package.xmlchanged-sources/force-app/main/default/labels/CustomLabels.labels-meta.xml:
and changed-sources/package/package.xml
1. Run deployment with
--source-dirDeploy result
2. Run deployment with
--manifestExpected result
Same as for above when using the
--source-dirflagActual result
System Information
{ "architecture": "wsl-x64", "cliVersion": "@salesforce/cli/2.30.8", "nodeVersion": "node-v20.7.0", "osVersion": "Linux 5.15.133.1-microsoft-standard-WSL2", "rootPath": "/home/ubnt2204/.nvm/versions/node/v20.7.0/lib/node_modules/@salesforce/cli", "shell": "bash", "pluginVersions": [ "@oclif/plugin-autocomplete 3.0.9 (core)", "@oclif/plugin-commands 3.1.4 (core)", "@oclif/plugin-help 6.0.13 (core)", "@oclif/plugin-not-found 3.0.11 (core)", "@oclif/plugin-plugins 4.2.5 (core)", "@oclif/plugin-search 1.0.16 (core)", "@oclif/plugin-update 4.1.13 (core)", "@oclif/plugin-version 2.0.12 (core)", "@oclif/plugin-warn-if-update-available 3.0.12 (core)", "@oclif/plugin-which 3.1.0 (core)", "@salesforce/cli 2.30.8 (core)", "apex 3.0.25 (core)", "auth 3.3.13 (core)", "data 3.1.1 (core)", "deploy-retrieve 3.2.16 (core)", "env 2.2.1 (user)", "info 3.0.27 (core)", "limits 3.1.10 (core)", "marketplace 1.0.25 (core)", "org 3.3.14 (core)", "packaging 1.26.3 (user)", "schema 3.1.3 (core)", "settings 2.0.27 (core)", "sobject 1.1.13 (core)", "source 3.1.15 (core)", "telemetry 3.1.13 (core)", "templates 56.0.16 (core)", "trust 3.3.10 (core)", "user 3.2.11 (core)", "@salesforce/sfdx-scanner 3.17.0 (user)", "sfdx-git-delta 5.27.0 (user)", "sfdx-hardis 4.25.1 (user)" ] }Additional information
Comparing the two results I can see that there's that one extra line in the Validated metadata that is showing the Unchanged CustomLabels file.
| Unchanged CustomLabels CustomLabels changed-sources/force-app/main/default/labels/CustomLabels.labels-meta.xmlOther than this and of course, the Metadata Replacement results which clearly show that those 2 labels have been changed
there's nothing else that's different.
I did deploy in both cases and the actual results in the org match the validate commands' output.
I also added manually to the package.xml another type like this:
And this did work but it caused a full deployment of all CustomLabels, which is really not desirable.
Expected final result
Deployment using the
sf project deploy start --manifest package.xmlshould have the exact same behavior assf project deploy start --source-dir changed-sources.I'm happy to provide any other details.
The text was updated successfully, but these errors were encountered: