When run in docker, all but sha1 is null

[optikalefx]

When I run this inside of docker, the sha1 is visible, but the others are null.

---- BUILD GIT INFO ---  {
   sha: '29xxx44f6e2b1axxxddaf88fcxxx70727xxx3',
   abbreviatedSha: 'xxx1adxxx4f',
   branch: null,
   tag: null,
   committer: null,
   committerDate: null,
   author: null,
   authorDate: null,
   commitMessage: null,
   root: '/srv/http/client',
   commonGitDir: '/srv/http/client/.git',
   worktreeGitDir: '/srv/http/client/.git',
   lastTag: null,
   commitsSinceLastTag: Infinity
 }

Docker file is FROM alpine:latest
and then basically

COPY . /srv/http/client
RUN npm i -g yarn
RUN cd /srv/http/client && yarn && node_modules/ember-cli/bin/ember build --environment production

[alexlafroscia]

This is biting us too after switching from Travis CI to GitLab CI

90 {
91   "sha": "bfe29570e56ab8a8f401e0eade150965f8a38613",
92   "abbreviatedSha": "bfe29570e5",
93   "branch": null,
94   "tag": null,
95   "committer": null,
96   "committerDate": null,
97   "author": null,
98   "authorDate": null,
99   "commitMessage": null,
100   "root": "/builds/movableink/front-end",
101   "commonGitDir": "/builds/movableink/front-end/.git",
102   "worktreeGitDir": "/builds/movableink/front-end/.git",
103   "lastTag": null,
104   "commitsSinceLastTag": null
105 }

[aaemnnosttv]

After digging into this a bit, I found that it has to do with missing directories in the .git/objects directory. Commit data parsing requires these as shown here:

git-repo-info/index.js

Lines 294 to 297 in 0ad56e5

	function getCommitData(gitPath, sha) {
	var objectPath = path.join(gitPath, 'objects', sha.slice(0, 2), sha.slice(2));
	if (zlib.inflateSync && fs.existsSync(objectPath)) {

After a fresh clone, I find that these are not created though. See here about unpacking all objects https://stackoverflow.com/a/16972155/1037938

This appears to not be specific to Docker as these directories do not exist with a fresh clone in MacOS either.

[rwjblue]

Hmm, thank you for digging into that @aaemnnosttv! Do you have repro steps that I could use to fix (e.g. clone this repo, using git v2.x.x, git-repo-info is unable to read XYZ value)?

[aaemnnosttv]

I don't have that at the moment @rwjblue but I'll try to provide it if you need it. As far as I can tell, you should be able to reproduce it with a fresh clone of any repo. As mentioned above, only the commit sha (full and short) and git paths are are available in the result from the command in this state. Specifically, all other commit data such as commit message, dates, author, etc are not present because the commit objects are not unpacked to read from.

[hennzen]

I had the same problem when building my project in GitLab CI.

When repos are cloned, the .git/objects/pack folder holds all objects in one packed file pack*.pack plus an index file .idx instead of the needed single object files/folders.

Solved it by first moving the .pack file away from there (since git doesn't like it there for unpacking), then doing a git unpack-objects.

See SO answer on How to unpack all objects of a git repository?

So my .gitlab-ci.yml job now looks like this, and voilà, all git-repo-info values are there.

image: node:12.13.0

variables:
  GIT_STRATEGY: clone

...

build:
  stage: build
  script:
    - mv .git/objects/pack/pack*.pack .
    - git unpack-objects < $(ls pack*.pack)
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist

...

Not sure whether GIT_STRATEGY was necessary, but that was my first try. Left it in there, because my repo is rather tiny. See GitLab docs on git strategy and more for large repo optimizations

[leondmello]

I have the same issue when running on Jenkins.
I tried the solution suggested by @hennzen but didn't work for me
My initial checkout looks something like

checkout([
            $class: 'GitSCM',
            branches: scm.branches,
            doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
            extensions: [[$class: 'CloneOption', noTags: false, shallow: false, depth: 0, reference: '']],
            userRemoteConfigs: scm.userRemoteConfigs
        ])

Then later, I checkout a specific tag with git checkout -f

[leondmello]

As a workaround, we changed our repository to use version-commit instead of git-tag-commit

[HarshRohila]

@hennzen solution worked for me
@rwjblue the issue is exactly what @hennzen described. It happens for any newly cloned repo. My team using this package, I will be happy to apply this fix and raise PR, if its fine