sfdx force:source:deploy Succeeds for fieldsets outside of the custom object folder while sfdx force:source:push Fails

[omarGhaznavi]

Summary

sfdx force:source:deploy Succeeds for fieldsets outside of the custom object folder while sfdx force:source:push Fails

I'm creating a fieldset in a directory outside of the custom object folder. My custom Object lives under: src/namespace/objects/MyObject__c.object-meta.xml My field set lives under: src/namespace/domain/MyObject__c/fieldsets/myFieldset.fieldSet-meta.xml

Expected result

Deployment should complete successfully with no errors.

Actual result

Error N/A An object 'MyObject__c.myFieldset' of type FieldSet was named in package.xml, but was not found in zipped directory

Additional information

Feel free to attach a screenshot.

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): sfdx-cli/7.68.6 darwin-x64 node-v12.18.0

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core) @oclif/plugin-autocomplete 0.1.5 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.0.1 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.7.10 (core) @oclif/plugin-update 1.3.10 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.0.7 (core) analytics 1.12.0 (core) generator 1.1.3 (core) salesforcedx 49.4.1 (core) ├─ salesforce-alm 49.4.0 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) ├─ salesforcedx-templates 48.32.0 (core) └─ custom-metadata 1.0.8 (core) sfdx-cli 7.68.6 (core)

OS and version: macOS Catalina Version 10.15.6

[clairebianchi]

@omarGhaznavi currently the source:push command does not support changing the structure of a Salsesforce project, would you please provide us with more information on your use case

[omarGhaznavi]

@clairebianchi our company has hit into Salesforce deployment limits in terms of files that can be pushed in a single directory. Most of our code base for one project was housed under src/namespace/common directory. We are trying to place the files under their correct domain structure. This particular issue was created for a brand new fieldset not an existing one.

Our code deployment scripts being used by developers and DevOps relies on sfdx force:source:push command. We were hoping the sfdx cli would be able to support that for new files. Thank you.

[mshanemc]

Can you try this with the new source:beta:push commands ?

The limits should now be the same (# of files) between push and deploy, and the same logic is used underneath.

Unless you need the sequential option (see announcement) because the deploy is too big, the behavior should be the same.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. Currently, there is not enough information provided for us to take action. Please reply and reopen this issue if you need additional assistance.

[jmccotter]

It looks like the new push commands regressed to this same behavior. Previously, the legacy push would allow us to push objects, fields, and the other object metadata in one push, and then push fieldsets and other types of object metadata in a later push by putting it underneath a folder with the object name without needing to redeploy the original set of object-meta.xml and other files from the first push. We can continue to use the legacy push and our code that fixes source tracking with forceignore updates to get around this, but we would really like to use the new push to take advantage of the connection tolerance improvements and source tracking properly respecting forceignore updates. The connection issues with the legacy push were becoming significant issues with more recent versions of SFDX.

The pushes we are doing would look something like this: First push with all the object metadata we can deploy without dependencies on non-object metadata. The later object files are in directories that are forceignored

• firstPushDirectory/objects/Custom_Object__c/ which contains the object-meta.xml file, fields, fieldsets, etc

Second push with forceignores cleared which contains the objects along with the pages (which have numerous dependent classes) they reference which is the whole reason we can't deploy the object metadata all together due to things like actionOverrides referencing VF pages

• secondPushDirectory/object/New_Custom_Object__c/ which contains a new object-meta.xml file with page references that require us to deploy it later along with fields, fieldsets, etc
• secondPushDirectory/object/Custom_Object__c/ which contains fieldsets and related fields that reference the the new object that could not be deployed earlier. It also contains webLinks that reference pages which weren't deployed earlier also. We did not need to redeploy the object-meta.xml file, fields, or other metadata that were deployed in the first push.

In regards to the sequential package directory deployment, our directory structure currently has a bunch of different directories under it and they don't need to be deployed all separately sequentially. Using the forceignore allowed us to group the directories together appropriately either in two or three groups of pushes. Unless you plan to allow multiple directories per sequential push or want me to submit an issue for that to request that, we would have to rearrange our directory structure to fit Salesforce's deployment and tooling limitations rather than based on our product.

[jmccotter]

@omarGhaznavi are you able to reopen this or can you ask them to reopen this. I believe I've given them the info they requested.

[omarGhaznavi]

@jmccotter There is no option for me to open this on Github. Can you please take ownership of the case or open a new one and link it to this if needed. I'm on PTO for a few days. Thanks

[mshanemc]

On the positive side, all the deployment code uses https://github.com/forcedotcom/source-deploy-retrieve so you shouldn't have these pesky "push vs. deploy" differences.

You might not like the answer, but SDR expects "child" metadata of CustomObject like FieldSet to be a child of a valid custom object, and that means having (at minimum) a valid object-meta.xml.

It can be nearly empty.

[jmccotter]

Yes I have noticed the behavior changed in later versions of SFDX since this post so this issue was good to close. Thanks!