I'm trying to follow Continuous Integration Using Salesforce DX trailhead module, however, I'm using my own repo (I didn't clone the sample repo that is provided).

I've used their .travis.yml file and I followed all the steps, so a Travis build is properly started whenever I push to my repo. I can see that the JWT-based authentication passes correctly, as well. However, the script always fails at the below line 498:

enter image description here

I tried running the above line directly from my local machine in the same project, connected to the same DevHub and it works, it creates a scratch org without a problem. I'm not sure what could be the issue?


Something weird is going on here. Build fails 9/10 times, even if I'm not changing .travis.yml or any relevant files (e.g. - just by updating README.md file, or re-running the build, it sometimes passes, but most of the time it still fails).

Below is the full stack trace that gets returned when I include the --json flag:

  "message": "Invalid record ID. Specify valid record ID value",
  "status": 1,
  "stack": "Error: Invalid record ID. Specify valid record ID value
    at /home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/jsforce/lib/connection.js:572:40
    at /home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/lodash/core.js:785:25
    at /home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/lodash/core.js:1049:13
    at baseMap (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/lodash/core.js:784:5)
    at Function.map (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/lodash/core.js:2033:12)
    at module.exports.Connection.retrieve (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/jsforce/lib/connection.js:571:7)
    at module.exports.SObject.retrieve (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/jsforce/lib/sobject.js:78:21)
    at _getConnection.then (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/salesforce-alm/dist/lib/force.js:387:106)
    at tryCatcher (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/promise.js:510:31)
    at Promise._settlePromise (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/promise.js:567:18)
    at Promise._settlePromise0 (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/promise.js:691:18)
    at Async._drainQueue (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/async.js:148:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/home/travis/.nvm/versions/node/v8.9.1/lib/node_modules/sfdx-cli/node_modules/bluebird/js/release/async.js:17:14)",
  "name": "Error",
  "warnings": [
    "All --json output, including on error, is moving to stdout. Use the SFDX_JSON_TO_STDOUT environment variable to move over to the new functionality. This will become the default in version 45."

Final update

I switched to GitLab Runners and the same script worked fine. I can only conclude that there is some underlying issue with Travis builds, but I don't how to solve it.

  • Maybe add the --json and --logLevel error flags to see if it shows anything else up, such as a clue about what the ID might be. – Daniel Ballinger Oct 23 '18 at 21:49
  • Are there any IDs in the definition file? I doubt it, but if there are it seems a viable candidate. If there aren't, I'd say this is a platform bug. – Matt Lacey Oct 24 '18 at 2:53
  • @MattLacey No ID in the definition file. It's very basic, you can see it here. – smukov Oct 24 '18 at 7:08
  • @DanielBallinger the --json flag just gave me a stack trace back, the error is exactly the same. The stack trace says that the problem is happening in jsforce libray: sfdx-cli/node_modules/jsforce/lib/connection.js:572:40 – smukov Oct 24 '18 at 7:12
  • @smukov Can you include the full stack trace in the question? It's likely the problem originated in whatever is calling the jsforce library. – Daniel Ballinger Oct 24 '18 at 7:25

Actual solution:

So I spoke to Tavis CI and they suggested testing the job again with the following extra configuration:

before_install: - unset CI - unset TRAVIS - unset CONTINUOUS_INTEGRATION

So far has worked every time for me with this added


Looks like the " -v HubOrg " option is causing the issue.

-v | --targetdevhubusername TARGETDEVHUBUSERNAME
A username or alias for the target Dev Hub org. Overrides the default Dev Hub org.

I tried it using the alias of the Dev Hub Org and it seems to work fine. It went past the step:

sfdx force:apex:test:run -u testorg1 --wait 10

  • Can you clarify your answer? the question shows that smukov is already using the -v option – David Reed Nov 10 '18 at 12:10
  • meant that the value provided in the example script "-v HubOrg", "HubOrg" should be a valid alias for the Org where you have the Env. Hub setup and to which you have authenticated. – CIPilotUser Nov 10 '18 at 18:00

So, pretty sure that this is a Travis CI thing... I've been fighting this for a bit last week myself and have managed to get a build reliably completing using Circle CI instead of Travis. Instructions and example repo here: https://github.com/forcedotcom/sfdx-circleci

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.