Our AWS pipeline which has been working for months has just started failing to deploy to Production with a strange error message "No org configuration found for name".
Successful connect
Error message and pipeline failure.
sfdx installed to ·[38;5;104m/usr/local/bin/sfdx
sfdx-cli/7.83.0-eba9c6a927 linux-x64 node-v12.18.3
CMD= /usr/local/bin/sfdx force:auth:jwt:grant --clientid (redacted) --jwtkeyfile /tmp/server.key --username (redacted) --instanceurl https://login.salesforce.com
› Warning: force:auth:jwt:grant is not a sfdx command.
Did you mean auth:jwt:grant? [y/n]: {
"status": 1,
"name": "NoOrgFound",
"message": "No org configuration found for name (redacted)",
"exitCode": 1,
"commandName": "SourceDeployCommand",
"stack": "NoOrgFound: No org configuration found for name (redacted)n at Function.create (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/sfdxError.js:160:16)n at AuthInfo.loadAuthFromConfig (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/authInfo.js:682:49)",
"warnings": [
"The error message "NoOrgFound" has been deprecated and will be removed in v46 or later. It will become "NamedOrgNotFound"."
]
}
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.
Hey, I'm reading that they changed auth into its own component.
https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md
So the new syntax should be sfdx auth:jwt:grant
Hi @sifer, i'm aware of that change - however the command has been aliased for now so it "should" continue to work as before was my understanding?
Update: changing our pipeline configuration to use "sfdx auth:jwt:grant" works - so it would appear to be the alias which is broken?
Same here, we have several CIs broken, alias doesn't seem to work.
I just took a look at our CI builds. Our builds update the CLI installation on the Docker image before working on the build. When I just checked on a build, it is upgrading to v7.84.2-a2868a68d5 .... not v7.83.0-eba9c6a927 that @anderg4.
Has Salesforce already fixed this? It is odd because npmjs.com is still showing v7.83.1 as the "latest" (re: npmjs.com entry on 'sfdx-cli')
Release process: an npm package goes at as latest-rc and then promoted to latest a week later.
For example, right now sfdx plugins:install salesforcedx@latest-rc will give you 7.85.0.
@mshanemc -- Understood, but how is my sfdx update command picking up v7.84.2-a2868a68d5 then? I don't see that on any of the npmjs aliases.
Sorry, we're not using npm. Our pipelines use wget to download the latest via:
wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz
which currently results in sfdx-cli/7.83.0-eba9c6a927 linux-x64 node-v12.18.3
We've changed to use the non-aliased command
sfdx auth:jwt:grant
and the pipeline is working again. It's definitely something in the aliased command - but we can live with it as we've now change syntax.
CLI has been rolled back - see https://github.com/forcedotcom/cli/issues/811
Exact same issue has been re-introduced.
Warning: force:auth:jwt:grant is not a sfdx command.
{
"status": 1,
"name": "NoOrgFound",
"message": "No org configuration found for name ***",
"exitCode": 1,
"commandName": "SourceDeployCommand",
"stack": "NoOrgFound: No org configuration found for name ***\n at Function.create (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/sfdxError.js:160:16)\n at AuthInfo.loadAuthFromConfig (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/authInfo.js:682:49)",
"warnings": [
"The error message \"NoOrgFound\" has been deprecated and will be removed in v46 or later. It will become \"NamedOrgNotFound\"."
]
}
Did you mean auth:jwt:grant? [y/n]:
sfdx retrieved into github action via:
wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz
the above results in sfdx-cli-v7.83.0-eba9c6a927-linux-x64 which appears to be the original non-working version from above rather than the correct repackaged version from Feb 5
Most helpful comment
Hi @sifer, i'm aware of that change - however the command has been aliased for now so it "should" continue to work as before was my understanding?