ENOENT While deploying permission sets

[Kostadin Stoev]

Hi Scott,

We are observing a weird issue, literally any metadata can be deployed from the project but the permission sets.

During the deployment using Cmd + S the following error pops: DeployMetadata - Error - ENOENT: no such file or directory, scandir ''

Sadly I can’t recreate it using another project but the current project deploys properly through Gearset.

Steps to recreate:

1. Create a project with manifest and fetch permission sets
2. Commit and push the project to git
3. Clone the repository and set a new connection
4. Do a small change in the XML structure of the permission set.
5. Deploy to the server

I have provided a log with the deployment debugging

[Scott Wells]

Hi. That message is coming from the Salesforce CLI command:

/usr/local/lib/sf/bin/sf project deploy start -o [e-mail] -c -r -g -x /private/var/folders/91/xklq2p6j2nzfz9pcd0kgw7nc0000gn/T/nexo_salesforce-NEXO_APIS-package.xml --async --json

which is returning the following:

{
  "status": 1,
  "exitCode": 1,
  "message": "ENOENT: no such file or directory, scandir \u0027\u0027",
  "name": "Error",
  "commandName": "DeployMetadata",
  "stack": "Error: ENOENT: no such file or directory, scandir \u0027\u0027\n    at ...",
  "actions": [],
  "warnings": []
}

when trying to deploy using the following package.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account_Anti_Phishing_R</members>
        <name>PermissionSet</name>
    </types>
    <version>60.0</version>
</Package>

You should be able to reproduce that behavior outside of IC2 by running that command directly from the command-line.

I would recommend uninstalling and reinstalling the Salesforce CLI in case it's an issue with the install. It's acutally quite common for the CLI to get into a bad state after repeated in-place updates unfortunately, and that class of issues is generally resolved by a scorched earth uninstall/reinstall.

However, it's possible that the error is a legit bug in the CLI or is coming from the server. If so, your best bet is to reproduce clearly using only the CLI and then log a bug in the CLI public issue tracker.

[Scott Wells]

I'm going to resolve this here since it does appear to be an issue with either the Salesforce CLI or perhaps even the server handling this request. If you find that it's not reproducible outside of IC2, or that there's some issue with the CLI command that IC2 is issuing in this specific case, please reopen with those details and I'll be happy to address it, of course.