8

I am running a ci task on my Gitlab server. One of the actions is to call an exe on the build runner machine which does some updates.

I pass through the SHA1s from $CI_COMMIT_BEFORE_SHA and $CI_COMMIT_SHA and the code calls:

git diff --name-only $CI_COMMIT_BEFORE_SHA $CI_COMMIT_SHA

Usually it gives me a list of file names which have changed in the commit but sometimes I get the error:

fatal: bad object abcd1234 ^ |-- This is the $CI_COMMIT_SHA

The repo has just been downloaded to the build runner so it is up to date, why would the git diff return a bad object here?

Improve this question
9
  • 1
    What runner are you using? Do you need to research difference between powershell and Linux shell? Commented May 19, 2021 at 16:46
  • 1
    According to stackoverflow.com/a/20264177/3216427, that message means the repository is corrupt. Do you get other strange file system issues in that setup? Do you see any other error messages from previous Git commands in the CI recipe? Commented May 19, 2021 at 17:49
  • 1
    I'm not sure the solutions there would be of any help, but stackoverflow.com/a/60971746/3216427 says doing an extra git fetch origin helped them. It's all a bit mysterious to me how a Git sandbox gets corrupted in the first place, unless something is unstable in the environment. Commented May 19, 2021 at 17:54
  • 3
    To clarify, does the error actually output fatal: bad object $CI_COMMIT_SHA with the variable not replaced or is the variable replaced? Commented May 19, 2021 at 19:29
  • 1
    @GaëlJ, it is with the variable replaced with the actual value Commented May 20, 2021 at 8:36

2 Answers 2

Reset to default
7

If the commit is "old" it could be missing from the clone because Gitlab uses a shallow clone with a depth of 20 by default.

This is why you see this message in the job's log:

Fetching changes with git depth set to 20...

Possible solutions:

  • use the web interface to increase this value for your project (or disable shallow cloning).
  • override variable GIT_DEPTH from .gitlab-ci.yml
  • re-clone the repo manually using a standard clone inside its .gitlab-ci.yml scripts
  • stop relying on "old" hashes
Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

The note about 'shallow clone' was key to helping me solve a similar problem with Azure DevOps pipelines using git diff-tree.... After I disabled shallow clone in the pipeline definition, then the git statement would work. Snippet of YAML - checkout: self clean: true fetchDepth: 0.
2

git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME git diff-tree --no-commit-id --name-only -r $CI_COMMIT_BEFORE_SHA -r $CI_COMMIT_SHA

It helped me!

Improve this answer

1 Comment

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.