Behavior changes based on version of git available (uses Github REST API on Ubuntu 18.04)

[rngadam]

The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH

This is quite confusing, I was trying to execute git operation on the repo and because it's from the REST API I can't... This is running on my own self-hosted runner.

Is this a new requirement? I thought this worked previously. I would prefer the workflow to fail instead - if not given a specific option to use the Github REST API.

Run actions/checkout@v21s
Resolved version clientdriver-client-android-releases-98f84cbf41dc1c59f53aab0785fe2c6428e352e8
Run actions/checkout@v2
  with:
    ref: refs/heads/ea-238
    repository: clientdriver/client-android-releases
    token: ***
    ssh-strict: true
    persist-credentials: true
    clean: true
    fetch-depth: 1
    lfs: false
    submodules: false
Syncing repository: clientdriver/client-android-releases
Getting Git version info
  Working directory is '/home/clientbotuser/build/github-actions-runner/clientdriver/client-android-releases/_work/client-android-releases/client-android-releases'
  /usr/bin/git version
  git version 2.17.1
Deleting the contents of '/home/clientbotuser/build/github-actions-runner/clientdriver/client-android-releases/_work/client-android-releases/client-android-releases'
The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH
Downloading the archive
Writing archive to disk
Extracting the archive
/bin/tar xz -C /home/clientbotuser/build/github-actions-runner/clientdriver/client-android-releases/_work/client-android-releases/client-android-releases/93eb6aa8-321e-4ac4-bed8-b9ad394505db -f /home/clientbotuser/build/github-actions-runner/clientdriver/client-android-releases/_work/client-android-releases/client-android-releases/93eb6aa8-321e-4ac4-bed8-b9ad394505db.tar.gz
Resolved version clientdriver-client-android-releases-98f84cbf41dc1c59f53aab0785fe2c6428e352e8

workaround on Ubuntu 18.04

latest official is 2.17 on Ubuntu 18.04

sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git -y

this gives me git 2.26.

[ericsciple]

Are you using a job-container? I just checked git --version on ubuntu-18.04 and it has git version 2.26.2

[rngadam]

@ericsciple I'm using a Github self-hosted runner on a EC2 server.

So this is referring to the version available by default on Ubuntu 18.04 of git:

https://packages.ubuntu.com/bionic/vcs/git

[ericsciple]

Ah ok, makes sense. The behavior is expected. When Git 2.18 or higher is not in the path, the action falls back to download the tarball. 2.18 is required because the action downloads a single SHA by default which requires git wire protocol v2 (available in git 2.18 or higher)

[rngadam]

@ericsciple yes, so what I'm saying is I don't think it should do that because the output is different (tarball vs git) and it's extremely confusing. Should fail-fast and require 2.18 (except if explicitly given a flag to fallback to this behavior).

[ericsciple]

Could potentially change behavior if we ever do a checkout v3.

Would disrupt existing users to change v2 behavior now.

[ericsciple]

On the bright side, should get better with time :)

Git 2.18 was released mid 2018.

[electrum]

We ran into this confusing issue as well with a self-hosted runner, since our build requires the .git directory to exist and it doesn't when using the archive.

[Simran-B]

FWIW yum install git on CentOS 7 installs Git 1.8 something. My workaround is to install a later version using https://ius.io/ in my Docker container (Git 2.24 Core in this case):

yum install -y \
    https://repo.ius.io/ius-release-el7.rpm \
    https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

yum swap -y git git224-core

Things like git rev-parse --short HEAD should work then, which in my case linuxdeployqt uses to determine the short SHA to add it to to the AppImage name.

Would be nice if there was a way to get the full as well as the short commit hash from the action as output even if the REST API is used, see #281

[haampie]

Requiring a git version not installable via apt-get install git in the oldest Ubuntu LTS release is frankly just absurd. It is a hard requirement if you need submodules too...

[Simran-B]

If you use GitHub Actions, then you can also use the GITHUB_SHA environment variable.
In bash scripts it can be shortened like so: ${GITHUB_SHA::8}
Using cmd on Windows it should be: %GITHUB_SHA:~0,8%

[ahvigil]

i agree with previous comments that this is somewhat confusing behavior- the checkout action doesn't actually do a checkout?

[wp-jm]

Ran into this as well, spent a few days debugging in other places because the checkout action was effectively a "dog not barking." The tarball checkout is semantically wrong; at the very least a tarball containing the same artifacts as if a true git clone was performed should be provided. This behavior will, for example, silently corrupt/break builds in python packages that depend on setuptools_scm as the call to get_version will fail.