Recent update to v4.1.4 has incompatibilities with older versions of git

[hicksjacobp]

With the recent release of v4.1.4, which was to address #1689, I am continuing to find issues with the behavior from actions/checkout, specifically for older versions of git.

To provide my details, analysis, and suggestions for resolution, I've created this minimal example: https://github.com/hicksjacobp/checkout-test

For summary, actions/checkout@v4.1.4 still causes a repositoryformatversion of 1 to be configured in the repository due to calling sparse-checkout disable. This appears to have been fixed in some version of git after 2.34.1.

The actions/runner image, which is the default image for actions-runner-controller, happens to NOT have a newer version of git than 2.34.1, and further requires adding of the apt feed to even install newer versions than 2.34.1.

The actions/runner image, which is the default image for actions-runner-controller, does not have git installed, nor the current apt feed for obtaining git versions newer than 2.34.1. If you install the GitHub CLI, then git@v2.34.1 is installed, using a Dockerfile definition like so:

FROM ghcr.io/actions/actions-runner:2.316.0@sha256:1a9c7d1bb0896c8a23572452174f517709199e327ca967081936a950a52e9ec1

ENV RUNNER_TOOL_CACHE=/home/runner/_tool

# Switch to root to install dependencies
USER root

# Install common packages
RUN apt update -y \
    && apt install -y --no-install-recommends \
        ca-certificates \
        wget \
    && rm -rf /var/lib/apt/lists/*

# Install GitHub CLI (gh)
RUN mkdir -p -m 755 /etc/apt/keyrings \
    && wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
    && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
    && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
    && apt update -y \
    && apt install gh -y --no-install-recommends \
    && rm -rf /var/lib/apt/lists/*

My intention with this issue is to raise transparency of the behavior change with actions/checkout@v4.1.4 which is different than actions/checkout@v4.1.1 for users that may not find this very obvious (the previous version which was pullable with v4). There are certainly some workarounds available as I put in the README of my minimal example.

Other References

• Recent Update to v4.1.3 Causes LibGit2SharpException with Sparse Checkout #1689

[hicksjacobp]

FYI @jww3

[jww3]

Hi Jacob,

Thank you for the bug report.

I have investigated and determined that git is not pre-installed on actions/runner images. Can you please clarify how you arrived at the following conclusion?

This scenario is exacerbated by the fact that actions/runner@v3.16.0 comes with git@2.34.1

As evidence, please have a look at https://github.com/jww3/checkout-test/actions/runs/8877937861 which is a pared-down version of your example workflow that focuses only on discovering the pre-installed git version.

Thanks,
@jww3

[hicksjacobp]

@jww3 that is...interesting. When I first encountered this, it was with an image extended from actions/runner in which I didn't have any additional steps to install git, yet was performing git functions and I observed that 2.34.1 was being used during a run.

I will do some more digging and get back to you.

[hicksjacobp]

Okay, so follow up.

I minimized my image that is built off of actions/runner. I found that git is being installed due to installing the GitHub CLI. In other words, this Dockerfile definition results in git@v2.34.1 installed:

FROM ghcr.io/actions/actions-runner:2.316.0@sha256:1a9c7d1bb0896c8a23572452174f517709199e327ca967081936a950a52e9ec1

ENV RUNNER_TOOL_CACHE=/home/runner/_tool

# Switch to root to install dependencies
USER root

# Install common packages
RUN apt update -y \
    && apt install -y --no-install-recommends \
        ca-certificates \
        wget \
    && rm -rf /var/lib/apt/lists/*

# Install GitHub CLI (gh)
RUN mkdir -p -m 755 /etc/apt/keyrings \
    && wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg | tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
    && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
    && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
    && apt update -y \
    && apt install gh -y --no-install-recommends \
    && rm -rf /var/lib/apt/lists/*

If I don't install the GitHub CLI, then git is not present in the image, just like you said git is not installed as part of actions/runner. I will update my original post to be more accurate.

Regardless, the update to actions/checkout@v4.1.4 adds or enforces a reliance on a newer version of git or using other workarounds that is not explicitly obvious nor expected from a semantic version update of just a patch version from actions/checkout. With using the default set of assets from GitHub - actions/checkout, actions/runner, GitHub CLI - it's unexpected to require taking additional steps to do something as basic as installing an appropriate version of git that works with the implementation provided.

I apologize that this observation is directly on actions/checkout. I decided to raise it here because the v4.1.4 release is what spurred my dive into rabbit hole. This does feel like some kind of bigger "ecosystem" environment across GitHub repositories.

From my perspective, I would think that follow up like these may be appropriate:

• actions/checkout should check which git version is being used and alter its behavior as appropriate. While sparse-checkout may have been added at 2.28, it appears from my observation that it results in a different repository state depending on the specific git version. Again, at least 2.34.1 is resulting in a repositoryformatversion of 1 which isn't expected/supported by other software.
• actions/runner could have the appropriate apt feed setup for installing newer versions of git
• GitHub CLI could check that it hasn't installed or isn't using a recent version of git and warn the user (or make it more of a peer dependency than a dependent one?)

[jww3]

If you install the GitHub CLI, then git@v2.34.1 is installed

I attempted to reproduce this. My investigation resulted in Git version 2.43.0 getting installed as a result of installing the GitHub CLI in a pristine Ubuntu container instance.

I'll talk to the GitHub CLI team about minimum Git version requirements.
I've also left a comment to guide us when it comes time to plan actions/checkout v5.

[hicksjacobp]

@jww3 For reproduction of what I'm seeing, use ubuntu:jammy instead of ubuntu:latest.

actions/runner depends on mcr.microsoft.com/dotnet/runtime-deps:6.0-jammy:
https://github.com/actions/runner/blob/04b07b6675c56da40e532ab73eeb4287bf223e34/images/Dockerfile#L2C31-L2C43

mcr.microsoft.com/dotnet/runtime-deps:6.0-jammy depends on ubuntu.azurecr.io/ubuntu:jammy:
https://github.com/dotnet/dotnet-docker/blob/0535bf7c536483266d36066bf2e87115106f2985/src/runtime-deps/6.0/jammy/amd64/Dockerfile#L1C6-L1C36

[jww3]

Ah, I see the issue on ubuntu:jammy

It looks like the latest guidance from git-scm.com is to use

add-apt-repository ppa:git-core/ppa
apt update 
apt install git

in order to get the latest version of git.

---

Here's what it took to get the gh cli installed with an up-to-date git version on ubuntu:jammy.

[jww3]

I've proposed the following PR: actions/runner#3273

[jww3]

actions/runner#3273 has been merged. The experience here should be improved in upcoming actions/runner releases. Specifically, apt update git should work seamlessly out-of-the-box.