Here is a workaround for this SFDC Platform Winter19 bug
Create/update .forceignore file at the root of your SFDX Project, with the following content :
# List files or directories below to ignore them when running force:source:push, force:source:pull, and force:source:status
# More information: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev....
It would be nice for this to be something in the actual CLI commands: the ability to clean up old orgs that are no longer needed.
For the time being, you need to manually cleanup the DX configs in the local installation.
On mac/linux, you can find your DX config folder, called .sfdx in your user home directory.
On windows, you can use %...
You can use sfdx force:config:set email@example.com.
You can use the additional -g parameter if you want to set it globally.
The related doc is here, in addition to using sfdx force:config:set -h.
You can also set afterwards your default Scratch Org using sfdx force:config:set firstname.lastname@example.org.
It looks like rather than deleting a hub org, you just call:
sfdx force:auth:logout -u <hub alias>
You'll get a warning about being sure you want to log out. Once you do, that hub org will no longer show up in the list.
This happens to me every couple of days on a Mac.
A workaround is to delete the directory /Users/xxxx/.local/share/sfdx/client and then sfdx-cli will automatically upgrade on the next command your run. See Cannot find module package.json #666. This includes the comment:
as discussed in #653 this was due to a cleanup process that was too
eager and ...
ALIAS USERNAME ORG ID CONNECTED STATUS
─── ──────────── ────────────────────────────────────────── ────────────────── ────────────────
DevHub email@example.com 00D7F0000000001AAA invalid_grant
I just had my trial ...
The problem was that I was using the domain name instead of the plain test.salesforce.com.
This doesn't work:
sfdx force:auth:web:login -r https://xyz.lightning.force.com/ -a XYZ
but this works:
sfdx force:auth:web:login -r https://test.salesforce.com/ -a XYZ
The easiest way to be able to view test coverage is to have set the --codecoverage flag (-c for short) to retrieve code coverage when you run the test command.
> sfdx force:apex:test:run -c -u myOrg -r human
Note that the -r output format flag is required when asking for code coverage
Let's stick that in a file
To save the output so you can go back ...
You are correct that you can only do a source pull from a Scratch Org. You can retrieve the source from a managed or unmanaged package. Just put everything you want to retrieve into an unmanaged package and then follow these steps
Well, the sfdx command that you included in your comment is the correct one to use. If you're worried about messing up your production environment, why not use sfdx to deploy to a sandbox first?
Any sandbox will work, but using a full copy or partial copy sandbox would make it easier because you'd have some amount of "real" data that you could play around ...
In the command palette, if you type "sfdx ex" you will be offered this if you have some Apex text selected:
SFDX: Execute Anonymous Apex with Currently Selected Text
SFDX: Execute Anonymous Apex with Editor Contents
if you don't.
Not too sure why there is also this .apex file thing too. As the project is open source you can see open issues, all ...
To install a managed package via sfdx, you do it the same way you do it with the metadata API. The command looks like this:
sfdx force:mdapi:deploy -d packages
The packages folder contains a package.xml file with the following contents:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
We had an auto release with a bug. We've rolled it back. Please run sfdx update and ignore the one time error you receive.
The team is already performing a retro to understand how this got out.
Sorry for the trouble.
Unfortunately, the CLI will always pull "Remote Add" metadata (ie. metadata not previously seen in any local SFDX Package Directory) into main/default/<metadata-type> inside of the default Package Directory specified in your project's sfdx-project.json file.
From the CLI's point of view, this behavior is by design. You need to have a place where ...
The short answer is: yes. All of the commands in the force:data command namespace work on any edition of Salesforce any org (provided API is enabled on that org).
The long answer is: it depends on what you need as far as data.
The full command list is as follows:
➜ ~ sfdx force:data
Usage: sfdx force:data:COMMAND [command-specific-options]
If you downloaded the Salesforce CLI during the Salesforce DX Pilot, you likely have version 5.6.X. Unfortunately, this is not upgradable to version 6 of the CLI. You'll have to uninstall. When you go to uninstall, be aware that it was using heroku in the binary path name, so you'll need to use this script from Dave Carroll: uninstall Salesforce CLI from ...
Have you tried using:
sfdx force:package:install -i 04t6A0000004eytQAA
Docs for this are found in the CLI command reference.
The only thing is that you'd need to know the ID of the package to pass to the command, but if you can get that, you should be in good shape.
After doing some playing around with this now, when you run the install of an ...
There is --resultformat on query.
sfdx force:data:soql:query -q "SELECT Id,Name,Status__c FROM Property__c" --resultformat csv`
I got that from the command help. See below.
-> sfdx force:data:soql:query --help
Usage: sfdx force:data:soql:query -q <string> [-t] [-r <string>] [--
perfloglevel <string>] [-u <string>] [--json] [--...
@smukov is correct, don't use the lightning.force.com url. Instead find that url here for your sandbox and log in using the instance that shows in the url during Log In or in the sandbox "location" column.
You have two choices. First, you can use force:package commands to create an unlocked package. You can install this in production with force:package:install; it is similar to installing an AppExchange package. Otherwise, you would need to use force:source:convert to get a mdapi style format, then use force:mdapi:deploy with the relevant test level (e.g. ...
For reasons best known to itself, DX tries to parse your sfdx-project.json file even when your operation isn't related to any particular project e.g. when you run
So, check the sfdx-project.json in your current directory for errors, or change directory to a known-good project.
This error is occurring because you have two different packages using the force-app path. Since you're specifying both -d and -p in your command the path you provide for the -d flag has to match up with path for the package you provide with the -p flag. But your path is used for both dreamhouse and th-dreamhouse, so your path doesn't actually match up with ...
This is what I would do:
Create a project in Force IDE or Mavensmate connecting to your sandbox and select all the metadata components and retrieve metadata. Trick here is that Force IDE and Mavensmate also creates package.xml
Now use the package.xml created in above step and use the below command as suggested in this answer
sfdx force:mdapi:retrieve --...
The above command is specific to the machine you used. So don't think your office laptop has any knowledge of what orgs you authenticated with and set as the default hub org and the default scratch org.
You will need to authorize all the orgs you have with your office laptop again, and create your scratch org again from the office CLI.
Yes, the DX CLI can run on Heroku.
Wade Wegner contributed this buildpack here:
EDITED: added some extra details on how to install it since the readme is minimalist and outdated:
1) create the Heroku app
2) Set the buildpack
heroku buildpacks:set https://github.com/heroku/salesforce-cli-...
As of Summer '19 (v46.0), the INVALID_OPERATION errors you were hitting are no longer an issue!
force:source:deploy now works when deploying to production. See an example below:
sfdx force:source:deploy -m ApexClass:MyApexClass -l RunSpecifiedTests -r MyApexClass_Test -w 3 -u MyProductionOrg
1.Verify the "Salesforce CLI" installed successfully or not
Go to → C:\Program Files\Salesforce CLI\bin → Verify sfdx.exe should be availble
2.Add this path to environment variables "Path"
Go To → Windows Search → Edit environment variables for your account
So this turned out to be pretty simple. You can create a plan.json with more than 2 steps. You need to make sure your total record count stays below 200, but as long as you set the saveRefs in the plan to true for each step you can manually change all your foreign keys to internal reference. This works particularly well if you export your records the right ...
This command follows the basic rules of SOQL in how it is implemented. Of course you must adhere to the limitations of relationship queries in SOQL as well. In this instance the important limitation is the that of only being able to query one level deep from Parent to Child. So you could get as far as
SELECT Id, Name,
(SELECT Id, Name FROM Opportunities)...