cli icon indicating copy to clipboard operation
cli copied to clipboard
verified publisher icon forcedotcom

Can't push when labels file is removed

Open geoffswift opened this issue 1 year ago • 6 comments

Summary

If I decide I don't want the labels in example.labels-meta.xml any longer, I would expect to be able to simply delete the file.

When I try to push this change with sf project deploy start the cli fails:

Error (MetadataTransferError): Metadata API request failed: force-app/main/default/labels/example.labels-meta.xml: File or folder not found

Steps To Reproduce

  • Use a source tracked project
  • Make a labels file
  • Push the change
  • Delete the labels file
  • Try to push again (this fails)

Expected result

The deploy succeeds with the labels which were in the labels file are removed from the org.

Actual result

The push fails with:

Error (MetadataTransferError): Metadata API request failed: force-app/main/default/labels/team.labels-meta.xml: File or folder not found

Additional information

The problem is actually worse than described. I might have a git branch where a new labels file is added. If I deploy that branch but then switch back to trying to deploy main, then I can't because the file is similarly deleted by git.

Issue may not be limited to labels metadata.

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.61.8",
  "nodeVersion": "node-v20.12.0",
  "osVersion": "Darwin 24.0.0",
  "rootPath": "/Users/[email protected]/src/cpm/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.5 (core)",
    "@oclif/plugin-commands 4.0.16 (core)",
    "@oclif/plugin-help 6.2.13 (core)",
    "@oclif/plugin-not-found 3.2.22 (core)",
    "@oclif/plugin-plugins 5.4.10 (core)",
    "@oclif/plugin-search 1.2.10 (core)",
    "@oclif/plugin-update 4.5.10 (core)",
    "@oclif/plugin-version 2.2.14 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.18 (core)",
    "@oclif/plugin-which 3.2.15 (core)",
    "@salesforce/analytics 1.4.26 (link) /Users/[email protected]/src/cpm/node_modules/@salesforce/analytics",
    "@salesforce/cli 2.61.8 (core)",
    "apex 3.5.0 (core)",
    "api 1.2.2 (core)",
    "auth 3.6.65 (core)",
    "community 3.2.35 (link) /Users/[email protected]/src/cpm/node_modules/@salesforce/plugin-community",
    "data 3.6.8 (core)",
    "deploy-retrieve 3.12.15 (core)",
    "info 3.4.9 (core)",
    "limits 3.3.32 (core)",
    "marketplace 1.2.26 (core)",
    "org 4.6.0 (core)",
    "packaging 2.8.10 (core)",
    "schema 3.3.34 (core)",
    "settings 2.3.23 (core)",
    "sobject 1.4.40 (core)",
    "source 3.5.21 (core)",
    "telemetry 3.6.15 (core)",
    "templates 56.3.21 (core)",
    "trust 3.7.32 (core)",
    "user 3.5.32 (core)"
  ]
}

geoffswift avatar Oct 19 '24 15:10 geoffswift

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] avatar Oct 19 '24 15:10 github-actions[bot]

Hello @geoffswift :wave: None of the versions of sf you shared match the latest release.

Shared: 2.61.8 Latest: 2.62.6

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

github-actions[bot] avatar Oct 19 '24 15:10 github-actions[bot]

Issue is still reproducible with 2.62.6

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.62.6",
  "nodeVersion": "node-v20.12.0",
  "osVersion": "Darwin 24.0.0",
  "rootPath": "/Users/[email protected]/src/cpm/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.5 (core)",
    "@oclif/plugin-commands 4.1.3 (core)",
    "@oclif/plugin-help 6.2.14 (core)",
    "@oclif/plugin-not-found 3.2.22 (core)",
    "@oclif/plugin-plugins 5.4.14 (core)",
    "@oclif/plugin-search 1.2.11 (core)",
    "@oclif/plugin-update 4.6.3 (core)",
    "@oclif/plugin-version 2.2.14 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.18 (core)",
    "@oclif/plugin-which 3.2.15 (core)",
    "@salesforce/analytics 1.4.26 (link) /Users/[email protected]/src/cpm/node_modules/@salesforce/analytics",
    "@salesforce/cli 2.62.6 (core)",
    "apex 3.5.1 (core)",
    "api 1.3.1 (core)",
    "auth 3.6.65 (core)",
    "community 3.2.35 (link) /Users/[email protected]/src/cpm/node_modules/@salesforce/plugin-community",
    "data 3.7.0 (core)",
    "deploy-retrieve 3.12.17 (core)",
    "info 3.4.9 (core)",
    "limits 3.3.32 (core)",
    "marketplace 1.2.26 (core)",
    "org 4.6.0 (core)",
    "packaging 2.8.11 (core)",
    "schema 3.3.34 (core)",
    "settings 2.3.23 (core)",
    "sobject 1.4.41 (core)",
    "source 3.5.21 (core)",
    "telemetry 3.6.15 (core)",
    "templates 56.3.22 (core)",
    "trust 3.7.33 (core)",
    "user 3.5.32 (core)"
  ]
}

geoffswift avatar Oct 19 '24 15:10 geoffswift

Hey @geoffswift, thanks for the issue.

I discussed this with another engineer on our team and we don't know if there is much that we can do to solve this exact use case. When you create a few Custom Labels in the org and retrieve them, it will create a single labels/CustomLabels.labels-meta.xml file that contains all of the individual Custom Labels. Once the file is deleted, we cannot look inside that file to find the names of the Labels that were deleted.

We cannot use * to delete all of them because the default name of the file is generic CustomLabels.labels-meta.xml. Using * could easily delete all custom labels across multiple package directories if the file had the same basename.

There are two work arounds that I can think of.

  • Use the sf project delete source --source-dir force-app/main/default/labels command.
  • Use the new (beta) custom source decomposition functionality for Custom Labels.
    • PR: https://github.com/forcedotcom/source-deploy-retrieve/pull/1392
    • Release Notes: https://github.com/forcedotcom/cli/tree/main/releasenotes#2567-august-28-2024
    • Basically you run sf project convert source-behavior --behavior decomposeCustomLabelsBeta2. This converts that single file into seperate file for each Custom Label. Deleting those individual custom label files and the deploying will correctly delete the label in the org

iowillhoit avatar Oct 22 '24 18:10 iowillhoit

Using sf project delete source didn't work out that well...

$ sf project delete source --source-dir force-app/main/default/labels/test.labels-meta.xml 
? This operation will delete the following files on your computer and in your org:
CustomLabels:CustomLabels
Are you sure you want to proceed? yes

 ─────────────── Deleting Metadata ───────────────

 Deleting with SOAP API

 ✔ Preparing 155ms
 ◯ Waiting for the org to respond - Skipped
 ✔ Deploying Metadata 899ms
   ▸ Components: 1/1 (100%)
 ◯ Running Tests - Skipped
 ◯ Updating Source Tracking - Skipped
 ✔ Done 0ms

 Status: Succeeded
 Deploy ID: 0Af8B00000vOSm9SAG
 Target Org: [email protected]
 Elapsed Time: 1.49s



=== Deleted Source

 FULL NAME    TYPE         PROJECT PATH                                       
 ──────────── ──────────── ────────────────────────────────────────────────── 
 CustomLabels CustomLabels force-app/main/default/labels/test.labels-meta.xml 
$ sf project deploy start --ignore-conflicts

 ─────────────── Deploying Metadata ───────────────

 Deploying v61.0 metadata to [email protected] using the v62.0 SOAP API.

 ✔ Preparing 152ms
 ◯ Waiting for the org to respond - Skipped
 ✘ Deploying Metadata 4.50s
   ▸ Components: 2/2 (100%)
 ◼ Running Tests
 ◼ Updating Source Tracking
 ◼ Done

 Status: In Progress
 Deploy ID: 0Af8B00000vOSmJSAW
 Target Org: [email protected]
 Elapsed Time: 4.76s

Error (MetadataTransferError): Metadata API request failed: force-app/main/default/labels/test.labels-meta.xml: File or folder not found

geoffswift avatar Oct 24 '24 18:10 geoffswift

We might typically have two branches, one includes a new labels file, and the other does not.

  • Push the branch with the label file
  • Switch to a branch without the label file
  • Try sf project deploy -> Fails because file in other branch is not present
  • Try sf project delete source -> Fails because file in other branch is not present

How are we supposed to get out of this situation? Some people would use a separate scratch org for each branch because of this...

I think the ideal here is to remove the error, so it's still possible to push. Can I maybe have it work that way with sf project deploy start --ignore-conflicts?

geoffswift avatar Oct 24 '24 18:10 geoffswift

Hm, I am seeing this also. I think part of the problem is that project delete source does not track source by default, but even with the --track-source option there are still issues.

Were you able to try the custom source decomposition for Custom Labels? That seems to work as you would expect.

I was able to find another work around for deleting the custom labels in a project.

  • Create a manifest for the labels
    • sf project generate manifest -m CustomLabels --name postDestructiveChanges.xml
  • Create an empty manifest
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>61.0</version>
</Package>
  • Deploy the empty manifest with the post destructive change
    • sf project deploy start --post-destructive-changes destructiveChangesPost.xml --manifest package.xml
  • Delete the local CustomLabels metadata file.
  • sf project deploy preview will show a clean status

iowillhoit avatar Oct 30 '24 19:10 iowillhoit

Thanks for the workaround recommendation. We are planning to migrate to the decomposed labels, so hopefully this will become a thing of the past.

geoffswift avatar Oct 31 '24 23:10 geoffswift

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.

github-actions[bot] avatar Dec 12 '24 02:12 github-actions[bot]