1

We are running DX with CI/CD using Jenkins. Our CI/CD scripts will create the scratchOrg properly, and provide the login details (domain, username, password) We use this to log in when there is a build error in the CI/CD test coverage.

The problem is, when we log in using these credentials, we are prompted for a verification code the first time logging in. Since the CI/CD scripts are beyond our control, the email for the user is usually not the same dev who wants to log in. This means the verification code will not be emailed directly to the user who needs it. If it's after hours, then we might need to wait a full day.

Is there an easier way to log into a CI/CD created scratch org?

Improve this question
1

2 Answers 2

Reset to default
2

You can use the JWT approach or the other alternative is to use the sfdx force:auth:sfdxurl:store command.

For the sfdx force:auth:sfdxurl:store you have to make sure you protect the Sfdx Auth Url.

Here are steps to implement this securely

  1. Output the sfdx force:org:display -u=<scratchorgalias/username>--verbose --json to a file

  2. Encrypt the file with the Auth URL using an open SSL. Store a random password in your CI environment variable. An approach is shown here

  3. Export the encrypted file.

  4. Decrypt the file using the password you have in CI environment variable. Make sure every attempt not to expose this password.

  5. Once you have a file with sfdx URL you can use the below command

    $ sfdx force:auth:sfdxurl:store -f

The file must contain only the URL or be a JSON file that has a top-level property named sfdxAuthUrl.

Update:

Ok so as mentioned in the comments you get sfdxAuthUrl property only if you authenticated to the org using force:auth:web:login

An alternative approach - A better approach which is more standard from docs

  1. Query the ScartchOrgInfos object

  2. Look for Auth Code and exchange the Auth-Code for the refresh token.

  3. Construct sfdx URL using the refresh token as below

    force://<refreshToken>@<instanceUrl>
Improve this answer
7
  • So--very cool approach, I had marked it as the answer, but when I tried it in my CI/CD build script, there was no "sfdxAuthUrl": in the resulting JSON. (the json also omitted the "clientId": property, but had all the other props) Is there another way to get the force:// url?
    – DaveS
    Oct 7, 2020 at 18:28
  • Bummer. The reason the authUrl was not included is shown at the end of the --help for sfdx force:org:display response: "Including --verbose displays the sfdxAuthUrl property only if you authenticated to the org using force:auth:web:login (not force:auth:jwt:grant)", and that login requires the verification code :-(
    – DaveS
    Oct 7, 2020 at 18:36
  • 1
    Aha I did not think about it! Well there is a super easy way! You can run a query on the scratchorginfos object and that should get you the auth code as well as all other info you need
    – Mohith Shrivastava
    Oct 7, 2020 at 18:39
  • 1
    I will update the approach soon once I am on keys
    – Mohith Shrivastava
    Oct 7, 2020 at 18:40
  • I just figured out another approach. I'll add it. It's really easy. All you need to have is the accessToken. I'll write that one up
    – DaveS
    Oct 7, 2020 at 18:49
0

If you have the accessToken, which you can display in the Build logs with: sfdx force:org:display -u <scratchorg/username> --json

Then, in a bash shell, cd into a DX folder, I suggest one that's expired or no longer in use

cd <someDXfolder>

Now use the instanceUrl from the logs in the following command:

sfdx force:config:set instanceUrl=<instanceUrl>

Finally, you can exec a DX "open" with the accessToken from the logs:

sfdx force:org:open -u <accessToken>

Note--if using "bash" shell, there is an exclamation point in your accesstoken (and possibly other special chars) that must be preceded with an "escape Char", or backslash ("\") That's it--the browser will open with no verification prompt!

Improve this answer
2
  • I strongly suggest you encrypt the access token and not print :) Pretty much a security violation if you print. Also sharing of the tokens should be safely done.
    – Mohith Shrivastava
    Oct 7, 2020 at 19:14
  • 1
    This accessToken is only for the scratchOrg that is created during the CI/CD deploy where it just runs the Apex Tests and our own Tests (which are deleted after each build). The only folks that have access to the CI/CD logs are the dev team. We do protect the access tokens of the DevHub and the target orgs, of course, but we have enough security otherwise.
    – DaveS
    Oct 7, 2020 at 23:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .