git version 2.45.1 makes a lot of our workflows fail. This affects all our repos/workflows using Git LFS

[fengkai-tink]

Description

In the recent release you have upgrade the git version to 2.45.1.
That upgrade leads to a huge problem, our workflows especially the ones uses GIT LFS start to fail due to following reason:

 │ exit code: 128
  ╰─> [9 lines of output]
      fatal: active `post-checkout` hook found during `git clone`:
          /tmp/pip-req-build-81t_gbyh/.git/hooks/post-checkout
      For security reasons, this is disallowed by default.
      If this is intentional and the hook should actually be run, please
      run the command again with `GIT_CLONE_PROTECTION_ACTIVE=false`
      warning: Clone succeeded, but checkout failed.
      You can inspect what was checked out with 'git status'
      and retry with 'git restore --source=HEAD :/'
      
      [end of output]

We have verified that we can disable it by assign GIT_CLONE_PROTECTION_ACTIVE = False to each individual reusable workflow.
However, we have so many workflows which relies on the different versions of reusable workflows that we can not go in and fix each individual of them.

This breaking change was introduced by the new git version.
Here is the relevant issue: git-lfs/git-lfs#5749
You have never warn customers in advance and caused huge problem at our company.

This is against your promise in the README:

For high impact changes, we will post these in advance to the GitHub Changelog on our blog and on twitter.

Ex: breaking changes, GA or deprecation of images

Please roll back the change to the Github Runners or try to downgrade the git version so that we can keep using github!

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

Ubuntu 20.04 (20240516) Image Update

Is it regression?

Ubuntu 20.04 (20240514) Image Update

Expected behavior

We can checkout code as normal

Actual behavior

We can not checkout code because of the git setting.

Repro steps

Fetch a repo that has LFS object

[erik-bershel]

Might be connected: #9882

[fengkai-tink]

Might be connected: #9882

Nope, it's not. It's related to LFS and git version in the image

[erik-bershel]

Hey @fengkai-tink!
As a workaround you may use next environment variable: GIT_CLONE_PROTECTION_ACTIVE=false. Unfortunately we cannot downgrade Git version due to security reasons.

[fengkai-tink]

Thanks @erik-bershel But this breaking change has messed up all our previously working workflows and it has not been notified in advance. Our company is using Github Enterprise. Is there anything you can do here?

And as I mentioned setting that variable for different version of our code + workflows is too much

Hey @fengkai-tink! As a workaround you may use next environment variable: GIT_CLONE_PROTECTION_ACTIVE=false. Unfortunately we cannot downgrade Git version due to security reasons.

[erik-bershel]

But this breaking change has messed up all our previously working workflows and it has not been notified in advance. Our company is using Github Enterprise. Is there anything you can do here?

Unfortunately, in this case, we and other users are exactly the same victims of circumstances. You can contact GitHub support or the Git developers if you have additional questions or suggestions. As for this repo “safety first” rule applies to the composition of the base image. Unsafe packages and options are used only if there are no alternatives or by users themselves.

[erik-bershel]

For better user awareness, we will keep this item open for a while (possibly until a new Git release).

[bzanin-wdc]

This has broken a few thousand CI/CD workflows in our organization, we are currently calling it a major fire.

[bzanin-wdc]

This issue is being hashed out between the git and the git-lfs developers in this email thread

[sardarhashimkhan]

Hi,

Is there any update on this? Our organization is facing same error while trying to install cocoapods from git in azure VM

fatal: active post-checkout hook found during git clone:
/private/var/folders/yv//T/d20240518-15213-5qrtml/.git/hooks/post-checkout
For security reasons, this is disallowed by default.
If this is intentional and the hook should actually be run, please
run the command again with GIT_CLONE_PROTECTION_ACTIVE=false
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

[fengkai-tink]

I have fixed it by setting GIT_CLONE_PROTECTION_ACTIVE=false in ALL the upstream reusable workflows. There is no way around this

[bzanin-wdc]

Per git-lfs/git-lfs#5749 as of 2024-05-22T09:00-05:00 (or around then) there is a patch series under review on the git mailing list working towards a 2.45.2 release with a fix for the git-lfs use case. If this 2.45.2 release happens soon and is rolled out to the runner-images as eagerly as 2.45.1, there might be some relief for this breakage soon.

[bitzer-sbc]

This seems to have to do with authentication for git lfs.
In my case adding this did the job:
git config lfs.<URL>.access basic
I noticed that calling 'git lfs env' in my build server working directory showed the endpoint with (access=None)

[bzanin-wdc]

The git 2.45.2 release on 2024-05-30 1718h-07:00 (1, 2) has rolled back the specific behaviour change that broke the git-lfs use case. This should remove the need for a workaround with the GIT_CLONE_PROTECTION_ACTIVE environment variable or a manual git lfs fetch step for repos that depend on git-lfs objects once it is rolled into an actions-runner release.

[mikhailkoliada]

all deployed (we deployed updated version without this variable set but the fixed version of git)