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
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.
Are you using a job-container? I just checked git --version on ubuntu-18.04 and it has git version 2.26.2
@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:
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)
@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).
Could potentially change behavior if we ever do a checkout v3.
Would disrupt existing users to change v2 behavior now.
On the bright side, should get better with time :)
Git 2.18 was released mid 2018.
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.
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
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...
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%
i agree with previous comments that this is somewhat confusing behavior- the checkout action doesn't actually do a checkout?
Most helpful comment
@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).