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. Oct 23, 2018 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, 2018 at 2:53
  • @MattLacey No ID in the definition file. It's very basic, you can see it here.
    – smukov
    Oct 24, 2018 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, 2018 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. Oct 24, 2018 at 7:25

3 Answers 3


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, 2018 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. Nov 10, 2018 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

You must log in to answer this question.

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