Looks like I have found already a culprit here.
It is very important to check sourceApiVersion property of project.json configuration.
Looks like this value was 44.0 in my project. Probably because I have created it before updating the salesforce-cli tool. Then I updated the CLI and even reinstalled it but the project version has not been changed.
To avoid the error on running sfdx force:source:pull run the following query through the tooling API and delete any records it returns (easily done in Dev Console):
SELECT Id, MemberType, MemberName FROM SourceMember WHERE MemberType = 'Workflow'
If you have any workflow metadata which you need to retrieve then use sfdx force:source:retrieve to pull these ...
Salesforce CLI use an access token to connect to your org. This means that even if you change your password or even your username it will still be connected to your org trough your username. If you want to revoke the access permission you can do it by navigating to Setup>Home>Apps>Connected Apps>Connected Apps OAuth Usage and block the Salesforce CLI app.
If the orgs are connected , a better option is to use change set since you can easily detect dependencies and add them .
Using sfdx you can use sfdx force:source:retrieve to accomplish this .
To retrieve profile you can use below .This also shows how to retrieve apex class and custom object along as well
$ sfdx force:source:retrieve -m "ApexClass, Profile:...
Sometimes processes fail unexpectedly and leave behind lock files. In most cases you should be able to manually remove the file by navigating to your local AppData folder (the file will live elsewhere on other operating systems) and deleting it from your file manager.
Sounds like you've been able to resolve this issue just by removing update.lock.
Ya, this is most likely from the CLI upgrade, and installing the plugin again probably won't help.
It might be because your alias contains .'s in it which I didn't think worked in v6 either. Can you try to update your alias and see if that resolves it?
sfdx force:alias:set newAliasWithoutDots=<yourscratchorg>
sfdx force:config:set defaultusername=...
"Regular" (Developer Edition) scratch orgs don't have the same feature set as Enterprise Edition orgs, or any arbitrary org. Packaging orgs often have a lot of features turned off, as well, to avoid inadvertent dependencies.
That makes pulling Profile metadata out of a scratch org for deployment to a non-scratch org... difficult, in many cases, and Data.com ...
This seems to be an issue in the Salesforce CLI plugin for pre-release. I am going to inform the team about it.
You can uncover the real error by executing below command
sfdx plugins:install salesforcedx@pre-release --log-level=error
Here is the original error
error Couldn't find any versions for "salesforcedx-templates" that matches "49.0.1-0"
Use the -w parameter so that each command waits for confirmation, and things proceed in order:
sfdx force:org:create -w 10 -s -f ./config/project-scratch-def.json -a ScratchOrg
sfdx force:package:install -w 10 --package 04t0M000001mF9bQAE
sfdx force:package:install -w 10 --package 04tG0000000LKgXIAW
sfdx force:package:install -w 10 --package ...
I suggest using the NPM to install and upgrade for ease of switching between versions.
With this approach, your CLI is not auto upgraded and it is upon you to upgrade by watching the npm registry and reading release notes here.
NPM is a package manager for Node.js. You will need to have Node.js latest version installed along with NPM.
Install Current ...
This error shows up even if you have the right node version installed in your environment. The reason why this happens is that the default Salesforce CLI installation ships with a node server bundled with it.
As of today (2020-01-18), the internal node version shipped with the CLI is 12.18.3 and the issue is that the pre-release Salesforce DX plugin expects ...
To see all the orgs you have with the aliases associated use the command:
To see all aliases you set:
To remove the alias alone, you can use the command:
sfdx alias:unset <aliasName1> <aliasName2> <aliasName3> ...
this will remove the alias, but keep the org.
If you want to remove the org you can ...
The URL to get the latest version of the Salesforce CLI is changed to https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-x64.tar.xz
Previously it was https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz
Also, the new URL no longer contains the install script. The updated documentation can be found ...
From the Source code, you can view here
The state field maps to one of these, It's the state of the local file when force source pull or push occurs.
The DUP can be generated when mdapi covert happens and two files with the same name exist. The documented use case is discussed here
This is not ...
Metadata API has 2 formats.
RenameMetadata is crud based called and not File-Based calls. Thus you won't be able to use force.com migration tool aka ANT or workbench for this purpose.
The easiest way to use crud based call is to use Metadata API Wsdl. You can download it by navigating it from
Trailhead Playgrounds aren't scratch orgs linked to your Dev Hub. They're closer to independent Developer Editions.
To authorize them for use with Salesforce DX, you need to first get your Trailhead Playground username and password. Each Playground will have an independent set of credentials. You can then authorize each Playground separately with
OK I figured it out on Mac OSX. For a single file -p works as follows:
sfdx force:source:deploy -p "force-app/main/default/layouts/Snapshot__mdt-Snapshot Layout.layout-meta.xml"
However, for multiple files with your -p argument, you need to surround each filename with escaped double quotes as follows:
sfdx force:source:deploy -p """...
We don't use pre-release or develop tags of salesforcedx. salesforcedx is bundled in the top-level sfdx-cli..
If you want next week's release early, you can say sfdx update stable-rc to switch, and sfdx update stable to go back to the "main" release.
You can see how pre-release is getting behind: https://www.npmjs.com/package/salesforcedx
The command expects to run in a Unix-like shell (e.g. bash, zsh, etc), but you're using PowerShell. The rm command in PowerShell works differently.
In a shell that supports this syntax, it means "--recursive --force", and is meant to delete all matching sub-directories and files, and ignoring permissions errors that can be ignored (such as read-only).
Yes, queues are supported.
sfdx force:source:deploy -p force-app/main/default/queues
The expected file name format is:
And the expected contents should look like:
<?xml version="1.0" encoding="UTF-8"?>
This is not full code and a pseudo-code at this point but should get you started. This also assumes its a pre-deploy hook for now.
Approach 1 - Establish another session using sfdx-core lib
You can use the sfdx-core library to use the keys stored in your local machine to easily establish a session.
The key here is to note that argv contains all the flags ...
Looks like the culprit was invalid folder structure, when I copied fields, by accident I copied the fields folder only, while intended was objects/Product2/fields
The wrong folder structure which was raising the error that the path is null:
The correct folder structure which works well:
OK I think I found the reason for the incorrect folder location.
Either that or I have broken my VSCode and CLI build???
so what is happening is the recordtypes that are named the same as the business processes (Sales Process) are conflicting some how and causing the recordtypes of the same exact name to be retrieved into the businessProcesses folder.
You can check the Metadata Coverage Report to figure out the JSON you need to enable specific features. You use this JSON file while creating the Scratch Org:
sfdx force:org:create -f config/my-scratch-org-config.json
You have a space in your file path, so the CLI thinks you're trying to add multiple paths. Make sure you either quote:
"/Users/salesforceDeveloper/Desktop/SFDC Project/Prod Migration/force-app/main/default/objects"
Or backslash escape:
/Users/salesforceDeveloper/Desktop/SFDC\ Project/Prod\ Migration/force-app/main/default/objects
Or ideally, move the ...
First off, the error message was misleading. A Salesforce developer helped me understand that the tooling api has a slightly different set of configurations, and that is why the package2-description.json was mentioned, even thought it has nothing to do with my sfdx project.
Second "If you are going to specify a dependent package by the 04t ID, then do not ...
You can use any of the types in the Metadata Types documentation. There is mostly a 1:1 relationship to those metadata types for the force:source:retrieve command. Settings are kind of an exception (e.g. Address Settings would be retrieved using Settings:Address), but I think that's the only one.
Edit: Updated Link. The types are located in the left nav ...