auth:git:save

The auth:git:save command allows you to save a username and password (or token) that can be used to authenticate with your Remote Git Repository. This then allows you to use the auth:git:credentialhelper command to authenticate with a remote Git repository on machines that may not necessarily have authentication already configured. A good example of this is CI/CD agents that are ephemeral and may be spun up or town down at any time.

note icon
note

The password that you save will be encrypted with the encryption key that you provide. You will need to use the same key to decrypt the password with the auth:git:credentialhelper command.

Options

  • --stack=<stackName>

    The name of the stack to target. Stack names are case-insensitive. Stacks are specific to license keys, and you can see a list of all available stacks with the stack:list command.

    This value is required if no valid default stack has been set, or if you would like to target a stack other than the one that is currently the default stack. You can use the stack:setdefault command to set or change the default stack.

  • -k|--encryptionKey=<key>

    The key used to encrypt or decrypt stored credentials.

    Required if:

    • You want the process to utilise previously encrypted credentials, or if you want the process to save credentials
    • AND the encryption key has not been saved locally with the auth:key:save command, or the key that has been saved locally is not the key that you wish to use

  • -u|--gitUsername=<username>

    Required. Prompted for when not specified, and possible to do so.

    The username to save. Supply a blank value to indicate that no value should be saved (or to clear out a previously saved value).

  • -p|--password=<password>|<token>

    Required. Prompted for when not specified, and possible to do so.

    The password (or token) to save. Supply a blank value to indicate that no value should be saved (or to clear out a previously saved value).

  • --location=[Local|StateStore]

    Default: Local.

    The physical location to save the credentials.

    • Local: The credentials are saved locally on disk and are specific to the current machine that the auth:git:save command is executed on. This is best suited to instances where you may have an ephemeral device and Git token. For example, a CI/CD platform may provision an agent and a Git token that last only for the duration of the current job.
    • StateStore: The credentials are saved remotely in our stack State Store. They cannot be read by a third party (including OrgFlow's employees or representatives) without the third party knowing the encryption key that you used to encrypt them. These credentials can be accessed by anyone with access to the stack and the encryption key. This is best suited to scenarios where you might need a central place to store the Git credentials required to authenticate to the remote Git repository.

The following options are global across all commands:

  • -h|--help

    If specified, prints help for this command instead of executing it.

  • -l|--licenseKey=<key>

    The License Key you were issued to allow you to use the OrgFlow CLI. If a valid key is supplied, it is stored locally on the machine so that it does not need to be specified again on the next execution.

  • --acceptEula

    If specified, you are signifying that you accept our End User License Agreement (EULA). You only need to specify this once per device, because your acceptance will be cached on the device (you can pass --acceptEula=false if you wish to clear this). You must accept our EULA to be able to run most OrgFlow commands.

  • --logTo=<filePath>

    If specified, a log file is written to the specified path. The specified path may contain one or more tokens; see Logging for more information.

  • --logLevel=[Verbose|Debug|Information|Warning|Error|Fatal]

    Default: Information

    The minimum log level to be written to the log file; logs below this level will not be written. Only effective if a valid value for --logTo has been specified.

  • --diagnostic=[Auto|Always|Never]

    Default: Auto

    If the CLI encounters an exception then it will ask (where possible) the user whether or not to create a Diagnostic Bundle and write it to disk. If it is not able to prompt then no action is taken. This is the default behaviour (Auto).

    You can change this default behaviour (and suppress the prompt) by specifying either Always or Never (which will always write the bundle or never write the bundle, respectively). This is particularly useful in a CI/CD context, where the CLI may not be able to prompt, but you still want to create diagnostic bundles for all failures.

  • --diagnosticDirPath=<directoryPath>

    If specified, sets the location to write the Diagnostic Bundle (if any). If not specified, a default location will automatically be chosen. This default location depends on a number of factors, including the operating system and some file-system based restrictions that might be in place. The location that the diagnostic bundle is ultimately written to is always included in the standard error output of the CLI.

  • --noConfirm

    If specified, suppresses confirmation prompts that the CLI might raise before performing destructive or dangerous procedures. If suppressed, the CLI assumes that the prompts would have been answered positively and continues with execution.

  • --progress=[Interactive|Never|Always]

    Default: Interactive

    Controls how progress is printed to the standard error stream:

    • Interactive: Progress is sent to the standard error stream only if the standard error stream is connected to an interactive terminal.
    • Never: Progress is not sent to the standard error stream.
    • Always: Progress is sent to the standard error stream, even if that stream has been redirected.

  • --tempDir=<directoryPath>

    If specified, sets the location to use as storage for files that may need to be stored on disk temporarily during command execution. For example, the location on disk where zip files containing metadata from Salesforce are downloaded to before they are unzipped.

    If not specified, the CLI will automatically choose an appropriate location on disk (usually in the current user's temporary storage location). This automatically chosen location may be deeply nested within a drive, which may be problematic if the operating system imposes limits on file path lengths and the files placed into temporary storage have particularly long paths or names.

  • --json

    Switches the format of the output sent to the standard output stream to JSON. This is the most verbose output available, and is useful for scripting or automation.

  • --forceSignIn.

    If specified, the CLI will ignore any cached Salesforce access tokens, and will require the Salesforce authentication process to be re-completed for each organisation that the command connects to.

  • --maxTransientErrorRetries=<count>.

    If no value is specified, the CLI will indefinitely retry any process that fails due to a transient error. This is the default behaviour, and allows for resilience against temporary issues that might otherwise cause a process to fail.

    Specify a positive integer value to prevent indefinite retries. Each process that fails due to a transient error will be retried up to a maximum amount of times specified. For example, --maxTransientErrorRetries=5: Each process that fails will be re-tried up to a maximum of five times. If an earlier process fails four times but then succeeds on the fifth attempt, the counter is reset for the next process.

    Specify --maxTransientErrorRetries=0 to disable transient failure retries.

  • --maxTransientErrorDelay=<seconds>.

    Default: 60

    Processes retried due to a transient error are delayed by a back-off policy that gradually increases the time to wait between retries. Specify a non-negative integer value as the maximum amount of seconds to wait between attempts.

    Specify --maxTransientErrorDelay=0 to disable the back-off policy and always instantly retry failed processes.

Examples

note icon
note

Some of these examples assume that the encryption key for the credentials has been saved using the auth:key:save command. This means that there's no need to specify the key with the -k|--encryptionKey option.

Save a username and password locally on the current device:

orgflow auth:git:save --username=myusername --password=mypassword

Save a username and password in the state store so that others with the license key and encryption key can use it:

orgflow auth:git:save --username=myusername --password=mypassword --location=statestore

Clear out a previously saved username and password:

orgflow auth:git:save --username= --password=

Generate an encryption key, use it to encrypt git credentials that are saved locally to the current device, and then add OrgFlow as a Git credentials helper. This is a common requirement on CI/CD agents where the agent is ephemeral and you need to configure Git with the credentials to clone or push to a repository.

# Cache the Git credentials locally:
encryptionKey=`orgflow auth:key:create`
orgflow auth:git:save -u="myusername" -p="mypassword" -k=$encryptionKey

# Add OrgFlow as a Git credential helper:
git config --global credential.helper "!orgflow auth:git:credentialhelper -k=$encryptionKey"