force:apex:test:run in JWT context seems to rely on the jwtkeyfile always being present

Summary

force:apex:test:run command fails when using JWT connection and the jwtkeyfile file is missing from project folder

Steps To Reproduce:

• Have jwtKeyFile at project root
• Authenticate to Dev Hub via JWT auth and make it defaultDevHub at least within the context of current SFDX project.
• Execute a scratch org creation
  • force:org:create --definitionfile config/project-scratch-def.json --json --setdefaultusername --durationdays 1
• Push of source code
  • force:source:push --json
  • executes correctly
• Conduct an Apex Test run
  • force:apex:test:run --testlevel RunLocalTests --outputdir target --resultformat tap --json
  • executes correctly
• remove jwtKeyFile from project directory
• Push of source code
  • force:source:push --json
  • executes correctly
• Conduct an Apex Test run
  • force:apex:test:run --testlevel RunLocalTests --outputdir target --resultformat tap --json
  • execution fails

Expected result

Execution of force:apex:test:run should succeed regardless of the presence of the jwtKeyFile

Actual result

Execution of force:apex:test:run fails if jwtKeyFile is not present in project directory.

Additional information

This becomes a blocker in Jenkins CI processes on SFDX projects. The recommended way to manage the jwtKeyFile on Jenkins is store it in the “Jenkins Admin Credentials interface.” During build job execution, Jenkins will checkout all code to the build job’s “workspace” folder. It will download the the jetKeyFile and other secret files to the adjacent folder “workspace@tmp” and inject that file during commands that explicitly utilize it (like the force:auth:jwt:grant command).

As it stands now, I am unable to utilize force:apex:test:run as part of my CI process.

SFDX CLI Version(to find the version of the CLI engine run sfdx --version):

• sfdx-cli/7.4.0-99233fd3af darwin-x64 node-v10.15.3

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core)

• @oclif/plugin-commands 1.2.2 (core)
• @oclif/plugin-help 2.1.6 (core)
• @oclif/plugin-not-found 1.2.2 (core)
• @oclif/plugin-plugins 1.7.8 (core)
• @oclif/plugin-update 1.3.9 (core)
• @oclif/plugin-warn-if-update-available 1.7.0 (core)
• @oclif/plugin-which 1.0.3 (core)
• @salesforce/sfdx-trust 3.0.2 (core)
• analytics 1.1.2 (core)
• generator 1.1.0 (core)
• salesforcedx 45.11.0 (core)
  • force-language-services 45.10.0 (core)
  • salesforce-alm 45.14.0 (core)
• sfdx-cli 7.4.0 (core)

OS and version:

• MacOS v10.14.4
• Ubuntu Linux (amd64) latest version

[jc-torrent]

@sanpatnaik Hello Friend! I was trying to do a similar thing, calling the mdapi deploy command. I gave up after a couple hours of trying to use a jenkinsfile to try this workaround. I prefer using Freestyle Jenkins projects because they are WAY easier to set up.

• I figured out what the problem was!

  • When using the secret file, as others have pointed out, the location of that file only exists until the end of the build. BUT! if you have already authenticated an org (even just in a prior build), it will still be trying to reference the file location that no longer exists!

• The solution I found was to logout of the org you are trying to authorize as the first part of the build step. Then re-authorize, then do your logic. Here is the build code I am using that is working now:

      export SFDX_USE_GENERIC_UNIX_KEYCHAIN=true
      cd test-ci
      echo y | /usr/local/bin/sfdx force:auth:logout --targetusername my-devhub
      /usr/local/bin/sfdx force:auth:jwt:grant --clientid {myclientId} \
      --jwtkeyfile $JWT_AUTH_KEY --username {myusername} \
      --setdefaultdevhubusername --setalias my-devhub
      /usr/local/bin/sfdx force:mdapi:deploy -d mdapi-out -u my-devhub -w -1 -c

Hello - Could you please provide more details on this as I am still facing the issue as John already mentioned - would love to have a workaround! Are you trying to say, authorize, logout and then re-authorize?

Hello! My issue in particular was that, once authorized, any additional builds will try to use the same authentication, because SFDX doesn’t remove authorized orgs. I am hosting jenkins on an ec2, so not locally. I log out of the org in the beginning of the build so that it is forced to re-authorize the org using the secret file. Because the secret file is only in a particular location for the duration of the build, if you don’t logout and then reauthorize, any commands that require authorization will look in the location from the first time you authorized the org to find the authentication file (the secret file).

[clairebianchi]

Sounds like there might still be an issue if you were able to run some commands and not others. Also maybe the documentation on Jenkins is wrong the way we are suggesting you set up isn’t correct. @shetzel could you shed some light on why the other commands worked but test:run failed?