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 firstname.lastname@example.org.
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 email@example.com.
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.
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 ...
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 ...
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
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 ...
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
ALIAS USERNAME ORG ID CONNECTED STATUS
─── ──────────── ────────────────────────────────────────── ────────────────── ────────────────
DevHub firstname.lastname@example.org 00D7F0000000001AAA invalid_grant
I just had my trial ...
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 ...
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"?>
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]
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
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 ...
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.
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] [--...
Unlocked Packages are more like an advanced form of Managed Packages, not Unmanaged Packages. Many of the same differences exist for Unlocked Packages and Managed Packages as compared to Unmanaged Packages.
Unlocked Packages can be upgraded, like Managed Packages. Unmanaged Packages cannot be upgraded without uninstalling.
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 ...
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
@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. ...
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 fix for me was to use the URL that the dev org redirected to after logout.
Logged into the dev org
Logged out of the dev org
Copied the URL
Executed this command in the terminal:
sfdx force:auth:web:login -r https://random-domain-somenumber.my.salesforce.com -a DevHub
That did the trick for me
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 ...
I had struggled to find this for a bit as I missed the section discussing this in the docs. I realized that the answer was in the same documentation CLI Runtime Configuration Values but was not clearly called out with respect to how to reset global values.
The documentation mentions:
To unset a configuration value, set it to no value. For example, to unset ...
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 ...
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.