force:source:deploy fails for labels in 7.113

[avisser]

Summary

Running force:source:deploy against labels fails 7.113 with the error "Not in package.xml". This is source-format project. I DON'T HAVE a package.xml.

Steps To Reproduce:

1. Go to any sfdx project
2. run sfdx force:source:deploy -p path/to/something.labels-meta.xml

Expected result

The labels are deployed

Actual result

$> sfdx force:source:deploy -p force-app/main/default/labels/Shared.labels-meta.xml

=== Component Failures [28]
Type   Name                             Problem
─────  ───────────────────────────────  ──────────────────
Error  accessDenied                     Not in package.xml
Error  assetConnectionErrorMessage      Not in package.xml
Error  assetConnectionErrorTitle        Not in package.xml
Error  associationsTitle                Not in package.xml

System Information

sfdx-cli/7.113.0 darwin-x64 node-v14.17.4

Reverting to 7.111.6 makes this issue disappear.

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

[WillieRuemmele]

Hi @avisser are these labels actually the CustomLabels metadata type? If so, then they must be stored in a CustomLabels.labels-meta.xml file according to the docs

I was able to resolve your issue by renaming the file from Shared.labels-meta.xml to CustomLabels.labels-meta.xml

[avisser]

If so, then they must be stored in a CustomLabels.labels-meta.xml file according to the docs

I don't think this is correct. Note this example from the LWC docs: https://developer.salesforce.com/docs/component-library/documentation/en/lwc/create_labels

In a Salesforce DX project, label files can live in any subdirectory of force-app/main/default. For example, this file named ExampleLabels.labels-meta.xml lives in force-app/main/default/mylabels.

[WillieRuemmele]

Interesting - it looks like there's conflicting information out there!

I've attached this issue to another one about issues with labels so they should be fixed together

[avisser]

Your link pointed me at the metadata API which I don't think I'm using with a dx project & force:source:deploy. Isn't that why force:mdapi:* exists?

[shetzel]

@avisser - all deploys and retrieves use the metadata API. There is always a manifest involved when deploying or retrieving. So this includes force:source:deploy, force:source:retrieve, force:mdapi:deploy, force:mdapi:retrieve, force:source:push, force:source:pull. With the force:source:* commands there is a conversion involved from source format to mdapi format (and vice versa). With the push and pull commands there is also source tracking involved.

[avisser]

@shetzel got it. Just a symptom of bad naming I guess.

[shetzel]

force:source:* commands work with metadata in source format. force:mdapi:* commands work with metadata in mdapi format. How would you prefer those commands to be named?

[avisser]

I was more commenting on the name collision between "Metadata API" and the mdapi (which I assume is short for metadata api) project format. What I'm reading is that they have nothing to do with each other, which is confusing.

[WillieRuemmele]

Hi @avisser this should be fixed in the latest-rc build of the cli 1.115.0, you can get it by either sfdx update stable-rc or npm install sfdx-cli@latest-rc --global depending on your preferred install method.

Please let us know if you're still seeing this in 1.115.0 of the CLI