I pushed a commit on Sunday, unknowingly during the GitHub outage. That commit didn’t seem to trigger a Travis build, presumably because the webhooks were paused. Yesterday I pushed some more commits, and those all started failing with this error:
Unhandled rejection Error: Command failed: /usr/bin/git checkout 1ffe576d8197b8319df50bd88681ec03990ce424
fatal: reference is not a tree: 1ffe576d8197b8319df50bd88681ec03990ce424
That commit doesn’t exist in the repo. What’s strange is that the header of the build page lists Commit 6180336 as what triggered the build, which is correct. Why isn’t the build checking out that commit, which it clearly knows about?
Things I’ve tried:
- Add git: depth: 99999 to .travis.yml
- Squashing the commits up to the last one that built
- Creating and pushing a new branch
I haven’t been able to find much useful info about the error. It doesn’t seem related to shallow clones, since the commit sha it’s trying to checkout just doesn’t exist at all. It 404s on GitHub.
Anything I can do to fix this?
Example bad build on travis-ci: fwextensions/quick-score-demo/builds/88725372
Repo on GitHub: fwextensions/quick-score-demo
(Not full URLs since I can’t post more than 2. :|)
This error message is coming from a dependency of yours. https://travis-ci.com/fwextensions/quick-score-demo/builds/88725372#L462 So you’ll have to look at what npm ci is supposed to be doing. The job checks out the correct commit. https://travis-ci.com/fwextensions/quick-score-demo/builds/88725372#L422.
I was literally just realizing it might be a module of mine that I’m including from GitHub temporarily. I was pointing at a branch of that repo, which I had deleted on Sunday. Since the outage happened at the same time, I thought it was related.
It’s a pretty confusing error message, made more so by my including a repo whose URL is just 5 letters off from the one I’m building.
Thanks for the help!
Hmm, I fixed the package.json to point to the branch on the other repo, but I’m getting the same error. Maybe I need to do a git clean on that repo and push it to GitHub? Not really a git expert.
The commit that Travis is trying to checkout does exist in the repo that it’s installing from GitHub via a URL in package.json. It was committed a couple weeks ago, and there have been builds since. But the branch that the commit was on was squash-committed into the develop branch, and then the original branch was deleted.
Still not sure how to fix this.
Commit Travis can’t find: https://github.com/fwextensions/quick-score/commit/1ffe576d8197b8319df50bd88681ec03990ce424
The commit may exist on GitHub, but it is not reachable if you clone it.
$ git clone https://github.com/fwextensions/quick-score.git
Cloning into 'quick-score'...
remote: Enumerating objects: 432, done.
remote: Total 432 (delta 0), reused 0 (delta 0), pack-reused 432
Receiving objects: 100% (432/432), 572.96 KiB | 7.34 MiB/s, done.
Resolving deltas: 100% (267/267), done.
$ cd quick-score
$ git checkout 1ffe576d8197b8319df50bd88681ec03990ce424
fatal: reference is not a tree: 1ffe576d8197b8319df50bd88681ec03990ce424
You’d have to find a way to not depend on this commit.
Thanks for the help. The thing that confuses me is why Travis is trying to checkout that commit. I can see why it had been failing before, but I’ve updated the package.json to specify a different branch that doesn’t include that commit. The branch that contained the commit was squash merged onto the branch I’m now specifying in the package.json.
Well, after reading up on what npm ci does, I figured out why Travis was trying to pull that unreachable commit. It was in the package-lock.json file:
"quick-score": {
"version": "github:fwextensions/quick-score#1ffe576d8197b8319df50bd88681ec03990ce424",
"from": "github:fwextensions/quick-score#feature/min-score"
},
I’d updated package.json and pushed that, but hadn’t run npm install again, so the lock file hadn’t been updated to point to the correct branch and the build continued to fail. After I committed the updated package-lock.json, the build is working again.
Good to hear that you were able to resolve it.
Posted a bug on the npm forum about this, as npm ci seems to behave differently on Windows vs. travis-ci (the build actually worked fine on Windows), and it didn’t warn about the mismatch between package.json and package-lock.json, which I think it’s supposed to.
That sounds like a different issue. I suggest opening a new topic. Thanks.