[JIRA] (JENKINS-60333) git LFS pull after checkout doesn't pull the files

0 views
Skip to first unread message

robojiannis@gmail.com (JIRA)

unread,
Nov 30, 2019, 6:40:03 AM11/30/19
to jenkinsc...@googlegroups.com
Jiannis S. created an issue
 
Jenkins / Bug JENKINS-60333
git LFS pull after checkout doesn't pull the files
Issue Type: Bug Bug
Assignee: Mark Waite
Attachments: jenk.rtf
Components: core, git-plugin
Created: 2019-11-30 11:39
Environment: jenkins 2.190.3, Git client plugin 3.0.0
Priority: Minor Minor
Reporter: Jiannis S.

I'm using jenkins on a windows 10 computer and the git plugin to build a unity3D project. The git repository (on bitbucket) contains lots of LFS files.
When checking the unity logs there are lots of files with the error "File could not be read". It seems like the LFS files aren't being pulled, although there aren't any git error in the console output (git LFS is already installed in the workspace).

Jenkins has already the behaviour "git LFS pull after checkout".

Am I missing out something obvious here?

Attached the console log

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 1, 2019, 9:55:02 AM12/1/19
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-60333
 
Re: git LFS pull after checkout doesn't pull the files

I don't see anything in the log you attached which gives any indication that git lfs fetch was unable to fetch files that were expected to be large files.

You indicate in your explanation that Unity is reporting that files cannot be read, but don't describe that you've checked the contents of the files in the workspace to confirm that they are large files as expected rather than being the "pointer" files that would be in the workspace if git lfs fetch had not been executed.

The contents of a git LFS pointer file are described in the Git LFS help. Please check the contents of the Jenkins workspace and confirm that the files have been updated with contents instead of being left with only pointer information inside the files.

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 1, 2019, 9:56:02 AM12/1/19
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
 
Change By: Mark Waite
Assignee: Mark Waite

robojiannis@gmail.com (JIRA)

unread,
Dec 1, 2019, 10:05:04 AM12/1/19
to jenkinsc...@googlegroups.com
Jiannis S. commented on Bug JENKINS-60333
 
Re: git LFS pull after checkout doesn't pull the files

I did check the content pulled from LFS. The pointer files are there but not the actual files which range from a few kilobytes to a 200-300 MB.

 

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 1, 2019, 10:22:02 AM12/1/19
to jenkinsc...@googlegroups.com

That is surprising. There is a line in the console log which shows that git lfs fetch was executed. There is no error message or other hint to indicate that the git lfs fetch detected any issue, and yet the pointer files are not updated.

What version of command line git is running on the agent? Command line git versions older than 1.8 are not supported with git LFS. Command line git versions are preferred to be 2.x with Git LFS, with the most testing performed on the more recent versions like 2.23 and 2.24.

What version of git LFS is installed on the agent? The majority of testing is done with the most recent release of git LFS.

What is contained in the .gitattributes file at the root of the workspace? Refer to my docker-lfs repository for an example .gitattributes file

Are any other messages logged which might indicate a problem with git lfs installed on the agent?

What is the output if you interactively perform a git lfs fetch from inside the workspace after the job has completed? Is there any indication that the command failed or that something went wrong?

What is the output if you interactively perform a git lfs install followed by a git lfs fetch inside the workspace after the job has completed? Is there any indication that the command failed or that something went wrong?

robojiannis@gmail.com (JIRA)

unread,
Dec 2, 2019, 3:36:02 AM12/2/19
to jenkinsc...@googlegroups.com
Jiannis S. updated an issue
 
Change By: Jiannis S.
Attachment: gitattributes.txt

robojiannis@gmail.com (JIRA)

unread,
Dec 2, 2019, 3:36:02 AM12/2/19
to jenkinsc...@googlegroups.com
Jiannis S. commented on Bug JENKINS-60333
 
Re: git LFS pull after checkout doesn't pull the files

+ command line git version 2.24.0.windows.1

+ git lfs version 2.9.0

+ running git lfs fetch in the workspace gives me "fetch: Fetching reference refs/heads/develop" and nothing else

+ running git lfs install gives me "Updated git hooks. Git LFS initialized". Running "git lfs fetch" after that gives me the same result as above

+ here's the gitattributes file: gitattributes.txt

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 2, 2019, 4:00:03 PM12/2/19
to jenkinsc...@googlegroups.com

If the file on the file system is named ".gitattributes.txt", that could be the problem, since is should be named ".gitattributes". I suspect that it is named correctly on your file system or you would have been unable to perform a `git lfs fetch` in any repository.

Can you confirm that the repository clones correctly with LFS file content correctly inserted when performed interactively?

Can you confirm that the repository clones correctly with LFS file content if you use the commands which are listed in the Jenkins console log?

I don't have any other ideas to suggest.

robojiannis@gmail.com (JIRA)

unread,
Dec 2, 2019, 4:04:02 PM12/2/19
to jenkinsc...@googlegroups.com

yes, I just renamed gitattributes with the *.txt suffix to upload it here
The repo works fine in all other cases, we're working with it all the time both on windows and mac using sourcetree or command line.

 

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 10, 2019, 1:48:03 AM12/10/19
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Cannot Reproduce
 

Since we're been unable to identify what is causes this bug to be visible, I'm closing it as "Cannot Reproduce".

Once additional information is available which identifies how to duplicate the bug, then it can be reopened.

Change By: Mark Waite
Status: Open Closed
Resolution: Cannot Reproduce
Reply all
Reply to author
Forward
0 new messages