- edited description
Unable to deploy: No authorization information found for -g
Hi Scott,
First of all, thank you for your excelled IDE! I’ve been using IC2 since the IC1 days, and it runs circles around any Salesforce supported IDE.
Unfortunately, I’ve run into an issue over the last week or so where deployments have been failing. I’ve only noticed this on one org - but not too sure how to resolve it. The CLI version is 7.195.2-29203e7. Retrievals work, just deployments seem to fail.
I’ve tried deleting the orgs setup from SFDX (remove the alias and stored data) and re-authenticating. The authentication works, but still doesn’t resolve the deployment issue.
The error is intermittent as well, and is different depending on what I am trying to deploy. I seem to generally be able to deploy LWCs, often able to deploy Apex, and it seems not able to deploy Apex.settings.
Below is the cli output:
Command line
============
C:/Program Files/Salesforce CLI/bin/sfdx.cmd force:source:deploy -u nic@redacted.io.mar -o -g -x C:/Users/User/AppData/Local/Temp/Redacted-MAR-package.xml -w 0 --json
Environment variables
=====================
SFDX_AUTOUPDATE_DISABLE = true
SFDX_JSON_TO_STDOUT = true
Duration
========
8 s 51 ms
Exit code
=========
1
Output
======
{
"code": 1.0,
"message": "Parsing --target-org \n\tNo authorization information found for -g.\nSee more help with --help",
"name": "NamedOrgNotFoundError",
"status": 1.0,
"stack": "NamedOrgNotFoundError: Parsing --target-org \n\tNo authorization information found for -g.\nSee more help with --help\n at Messages.createError (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\core\\lib\\messages.js:428:16)\n at AuthInfo.init (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\core\\lib\\org\\authInfo.js:528:28)\n at async AuthInfo.create (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\kit\\lib\\creatable.js:57:9)\n at async Org.init (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\core\\lib\\org\\org.js:764:27)\n at async Org.create (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\kit\\lib\\creatable.js:57:9)\n at async maybeGetOrg (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\plugin-source\\node_modules\\@salesforce\\sf-plugins-core\\lib\\flags\\orgFlags.js:16:16)\n at async getOrgOrThrow (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\plugin-source\\node_modules\\@salesforce\\sf-plugins-core\\lib\\flags\\orgFlags.js:51:17)\n at async Parser._parseFlag (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\parser\\parse.js:262:33)\n at async Parser._flags (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\parser\\parse.js:215:35)\n at async Parser.parse (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\parser\\parse.js:161:23)\n at async Object.parse (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\parser\\index.js:18:20)\n at async Deploy.parse (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\command.js:198:25)\n at async Deploy.run (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@salesforce\\plugin-source\\lib\\commands\\force\\source\\deploy.js:32:23)\n at async Deploy._run (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\command.js:108:22)\n at async Config.runCommand (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\config\\config.js:328:25)\n at async run (C:\\Users\\User\\AppData\\Local\\sfdx\\client\\7.195.2-29203e7\\node_modules\\@oclif\\core\\lib\\main.js:89:16)",
"exitCode": 1.0,
"warnings": [
"We plan to deprecate this command in the future. Try using the \"project deploy start\" command instead."
]
}
Error
=====
My hypothesis is based on this part of the message Parsing --target-org \n\tNo authorization information found for -g.\nSee more help with --help
and that removing the -o
and -g
resolves the error.
Is there something that jumps to mind that will help me resolve or further debug this issue? Also, this is a minor one as I do have a good enough work around and it could be a bug in the CLI.
Cheers
Nic
Official response
Comments (22)
-
reporter -
reporter Current easiest workaround I can think of is to run the following after each failed deployment:
sfdx force:source:deploy -u nic@redacted.io.assets -x C:/Users/User/AppData/Local/Temp/Redacted-MAR-package.xml -w 0 --json
-
reporter - edited description
-
reporter - changed component to Deployment and Retrieval
-
reporter - marked as minor
- edited description
-
reporter - edited description
-
repo owner Hi. That’s a valid CLI execution, so my guess is that there’s something wrong with your CLI install, and yours is definitely a quite old install based on just the installation path of
C:/Program Files/Salesforce CLI
. The CLI has installed intoC:/Program Files/sfdx
for quite a while now, and in the interim Salesforce has completely repackaged the CLI as they’ve moved toward a full open source offering. I know you mentioned that your install is up-to-date, but unfortunately I’ve seen CLI installs--my own included--get into a bad state after repeated in-place upgrades.You should be able to reproduce this in isolation of IC2 by running the following directly from the command-line:
sfdx.cmd force:source:deploy -u nic@redacted.io.mar -o -g -x C:/Users/User/AppData/Local/Temp/Redacted-MAR-package.xml -w 0 --json
which should fail with the exact same error.
I recommend that you completely uninstall and reinstall the Salesforce CLI. Please let me know if a scorched earth reinstall doesn’t resolve this issue for you.
-
reporter Hey Scott,
I think it’s not an IC2 issue - but probably a CLI issue maybe? I’ve just scorched the earth and hard deleted every reference and checked the cmd and paths manually to ensure hard deletion. The install path has changed since reinstalling (I guess it’s been a long time since I’ve changed my environment :)). Maybe there is something deeper going on and I’ve left some artifacts behind in my uninstall?. Still getting the same error.
I have a workaround, so not the end of the world. From working with it today, it seems to impact deployments of slightly less common metadata types (like
*.settings-meta.xml
,*.quickaction
, and*.layout
so far). I think the other types may have failed due to other items in the package.If you haven’t had other reports like this, I think it must still be an issue local to me or the CLI. Please get back to me if you see someone else possibly with the same issue, but I’m sure it’s not an IC2 problem (as it does fail in CMD with the same commands IC2 uses).
Thanks for your trademark quick response! Much appreciated!
Cheers
Nic
-
repo owner Nic, I think your best bet is going to be reproducing it 100% from the command-line and then filing a bug in the CLI public issue tracker:
https://github.com/forcedotcom/cli
They should be able to help discern whether this is an installation issue and therefore how to resolve it, or if it’s a CLI bug in which case they can schedule a fix.
-
repo owner - changed status to open
-
reporter Thanks Scott,
Sorry I’ve been slow to respond. I think you’re right, it’s certainly a CLI issue. I’ll try create a repro repo and submit that with them later this week.
Cheers
Nic
-
reporter - changed status to resolved
Resolving as this is almost certainly a CLI bug.
-
repo owner Okay. If/when you do file a case with them, please post a link to it here as I’d like to add myself as a watcher on it. Thanks!
-
Hi Scott and Nic,
I have this same issue.
It seemed to me that if IC2 changes to use the long FLAGS of -o and -g, we don’t have to wait for Salesforce CLI team’s fixing.
Suggest to change line 2 to line 3 below: -u USERNAME@LIKE-DOMAIN -o -g -x --target-org=USERNAME@LIKE-DOMAIN --ignoreerrors --ignorewarnings --manifest=
Versions
sfdx version ==> sfdx-cli/7.196.8 win32-x86 node-v18.15.0 IC2 version ==> 2.2.6.2 IDEA Build#IU-231.8109.175
When I run ‘sfdx force source deploy -h’, I saw some FLAGS as below.
-g, --ignorewarnings -o, --ignoreerrors -o, --target-org=<value> -x, --manifest=<value>
Possible issue:
Salesforce CLI may have changed the '-o, --target-org=<value>' to take higher priority over '-o, --ignoreerrors'. So in the Messages tool window when IC2 sending Comment Line '-u USERNAME@LIKE-DOMAIN -o -g -x', because '-g' was after '-o', the new version of Salesforce CLI expected -g as a USERNAME@LIKE-DOMAIN. So now '-g' is making sense as the above screenshot, 'No authorization information found for -g. ' (Because Salesforce CLI thought that -g after -o should be a USERNAME@LIKE-Domain, but CLI didn't like -g as a USERNAME.)
Scott, is it possible to release a new version of IC2 with the suggested changes in the first code snippet above?
It seemed to me that using the long FLAGS will likely prevent the similar issues in the future, e.g., new -o taking priority over old -o as the third code snippet above. -
repo owner Ah, that’s a good find, Peter! I’ll see if that takes care of it locally and, if so, I’ll include that change to the CLI argument ordering for Thursday’s build.
-
Scott and Nic,
My deployment succeeded when I took the following actions with IC2.
- Ctrl + Alt + Shift + F10
- Uncheck “Ignore Errors” checkbox
- click “Deploy” button
The Messages tool window (-o was removed)
-u USERNAME@LIKE-DOMAIN -g -x
-
repo owner Yeah, Peter’s workaround (uncheck Ignore Errors) is the one to use for the next two days, but I’ll update IC2 to use the long-form option, so
--ignoreerrors
instead of-o
. However, this is one of several breaking changes in the CLI-as-an-API contract that should be 100% reliable. I’m reporting them to Salesforce now including this one:https://github.com/forcedotcom/cli/issues/2080
So yeah, for those hitting this issue, please disable “Ignore errors” when deploying, and Thursday’s build should have a true fix (well, technically a workaround, but transparent for end users).
-
repo owner - changed status to open
Reopening as I'm including a fix/workaround for this in the coming build.
-
Just wanted to thank you, Scott, for a fix in the upcoming build. I've spend around 2 hours in total to find the “-o” flag duplicate, and I'm extremely happy to know that you already aware of it, and already talked to salesforce guys about it
-
repo owner You bet, and kudos to the Salesforce folks as well for acting so quickly on the issue (and one other I opened today). I may go ahead and release the new build tomorrow, but that all depends on how well the last round of testing goes tomorrow morning. Otherwise it will be Thursday.
-
repo owner - changed status to resolved
Delivered in 2.2.6.3.
-
repo owner - changed component to Metadata Deployment/Retrieval/Removal
- Log in to comment
Yeah, Peter’s workaround (uncheck Ignore Errors) is the one to use for the next two days, but I’ll update IC2 to use the long-form option, so
--ignoreerrors
instead of-o
. However, this is one of several breaking changes in the CLI-as-an-API contract that should be 100% reliable. I’m reporting them to Salesforce now including this one:https://github.com/forcedotcom/cli/issues/2080
So yeah, for those hitting this issue, please disable “Ignore errors” when deploying, and Thursday’s build should have a true fix (well, technically a workaround, but transparent for end users).