Closed BrentHebertZayo closed 2 years ago
Are you able to reproduce with 7.76.1
(latest)? I had a ton of issues with the last couple releases that we rolled back our dev-ops deploy bot to 3-4 months old releases.
I was able to have a bunch of users with different versions try it out and I know 7.74.0
up to latest had the same behavior, so I'm guessing that everything after 7.73.0
behaves one way and everything 7.72.0
and earlier behaves the other way.
@BrentHebertZayo what was the workaround you found? I am experiencing a similar issue with the official Salesforce extensions for VS Code.
@frankpeleato I think the easiest workaround is to retrieve the whole object folder if you use the -p flag. So sfdx force:source:retrieve -p "force-app/main/default/objects/yourObject/"
worked for us. Otherwise you can always fall back to the -x flag and use a package.xml to get the object.
@frankpeleato I think the easiest workaround is to retrieve the whole object folder if you use the -p flag. So
sfdx force:source:retrieve -p "force-app/main/default/objects/yourObject/"
worked for us. Otherwise you can always fall back to the -x flag and use a package.xml to get the object.
@BrentHebertZayo Thank you for answering. That is what we have been doing, as well.
I'm marking this closed since we changed the library handling deploy/retrieve. If you're still seeing problems with the -x
please open a new issue.
I'm still filling this out, but I have other work things to address. So I will come through again to fill in more detail.
Summary
When retrieving recordtypes from a sandbox with the sfdx force:source:retrieve -p or -x commands via 7.75 and 7.72 we got totally different results. One came back with "the whole" record type, the other came back with "the minimum".
Steps To Reproduce:
Repository to reproduce: dreamhouse-lwc
NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.
Expected result
We should get the same results.
Actual result
7.72 returns the full record type file (~5116 lines). 7.75 returns an incomplete file (~90 lines). Below is the short one.
Additional information
I have found a work around for this change, but it threw all of my users off. Since we are trying to keep our code base version controlled I need my users to be able to commit "the whole" files instead of just partial clumps. The fact that this kind of behavior change was due to a minor version change without warning concerns me for any automation I try to build out going forward. So I want to double check if this is intended behavior, and if so how do I get ahead of it?
SFDX CLI Version(to find the version of the CLI engine run sfdx --version): 7.72 and 7.75
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.2.0 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.9.0 (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-diff 0.0.6 @salesforce/sfdx-trust 3.4.3 (core) alias 1.1.2 (core) analytics 1.12.1 (core) config 1.1.8 (core) generator 1.1.3 (core) salesforcedx 49.13.0 (core) ├─ salesforce-alm 49.12.1 (core) ├─ templates 49.9.1 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) ├─ apex 0.1.0 (core) └─ custom-metadata 1.0.10 (core) sfdx-cli 7.75.0 (core)
OS and version: Mac Catalina