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 %...
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 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.
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.
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 to ...
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 ...
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 ...
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
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.
In the Summer 20 release, the componentInstances property for FlexiPage regions has been removed. These need to be replaced with itemInstances as outlined in the release notes. More details on the structure of an ItemInstance metadata type is in the guide.
For orgs that have been refreshed into the new version (like sandboxes and your production org at the ...
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 ...
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
@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.
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
The following solution worked for me
Run command prompt 𝐚𝐬 𝐚𝐝𝐦𝐢𝐧 (𝘚𝘵𝘢𝘳𝘵 > 𝘤𝘮𝘥 > 𝘙𝘪𝘨𝘩𝘵-𝘊𝘭𝘪𝘤𝘬 > 𝘙𝘶𝘯𝘈𝘴 𝘈𝘥𝘮𝘪𝘯)
Run the command: 𝐧𝐞𝐭𝐬𝐭𝐚𝐭 -𝐚𝐨𝐧
CTRL+F, to search for 𝟏𝟕𝟏𝟕
Note the number displayed in the 𝐏𝐈𝐃 𝐜𝐨𝐥𝐮𝐦𝐧 in the same row where 1717 was found. In my case, it's 𝟒𝟔𝟒𝟖
Open Task Manager > Click on ...
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 ...
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] [--...
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]
Now with the latest sfdx update(7.21.0) you can run 'sfdx force:source:deploy' command with specific test classes. Check below command.
sfdx force:source:deploy -p "./PathToMetadata" -l RunSpecifiedTests -r TestClass1,TestClass2 -w 33 --verbose --loglevel fatal
To install a First Generation 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"?>
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. ...
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 ...
What is the difference between force:source vs force:mdapi?
The file and directory structures are different. force:source refers to the new "source" format, while force:mdapi refers to the old "metadata" format. As an example of the changes, in metadata format, a custom object is a single file, while in source format, an object has a core metadata file for ...
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.
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
As for me, the most important difference is that the unlocked package uses SFDX for development. So you, as a developer, could create a package, create a new version, promote, install to org within only SFDX. So it is possible to script all required actions, so that automate the process and use CI in the development of the package.
You are suppose to call the method like
with the name of parameter not just the value
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 ...