Unable to deploy: No authorization information found for -g

Issue #2338 resolved
Nic Edwards created an issue

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

  • Scott Wells 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).

Comments (22)

  1. Nic Edwards 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
    

  2. Scott Wells 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 into C:/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.

  3. Nic Edwards 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

  4. Scott Wells 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.

  5. Nic Edwards 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

  6. Scott Wells 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!

  7. Peter Lin

    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.

  8. Scott Wells 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.

  9. Peter Lin

    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
    

  10. Scott Wells 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).

  11. Oleg Malitsky

    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 💛

  12. Scott Wells 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.

  13. Log in to comment