You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Short preface: even though the argument key is --branch, the docs saying that the argument is <git-ref> had left me hopeful that it wasn't restricted to branches. My first try at providing a commit SHA didn't work. I don't recall the exact failure. That was on an older version, and upon reading the "if you have no choice" from https://docs.earthly.dev/best-practices#git-clone-vs-run-git-clone, I went with that approach.
I recently had a separate need to clone from a tag. Figuring I might have some luck getting earthly to use a tag vs. SHA, I tried again (with a version newer than my previous attempt). It fails with panic interface conversion: interface {} is syscall.WaitStatus, not unix.WaitStatus. When searching for existing reports, I found #1211 . The two comments suggest that both commit SHAs and tags should work. While commits and tags might technically be undocumented/unsupported behavior, the fact that tags failed with a panic (vs. validation error) is why I decided to report.
To reproduce:
$ earthly -v
earthly version v0.6.2 linux/amd64; Debian testing
Earthfile:
FROMalpinetag:
# What I originally hoped would work in my scenarioGIT CLONE--branch v2.30.0 https://git.kernel.org/pub/scm/git/git.git tdir
commit:
# But I would be happy with this (the tag's SHA), which is implied *should* work in #1211 GIT CLONE--branch 71ca53e8125e36efbda17293c50027d31681a41f https://git.kernel.org/pub/scm/git/git.git cdir
signed:
# kind of works... the SHA for the "signed" tagGIT CLONE--branch 2d9685d47a7e516281aa093bf0cddc8aafa72448 https://git.kernel.org/pub/scm/git/git.git sdir
$ earthly prune --reset && earthly +tag
buildkitd | Restarting buildkit daemon with reset command...
buildkitd | ... Done. Future runs will be faster.
1. Init 🚀
————————————————————————————————————————————————————————————————————————————————
buildkitd | Found buildkit daemon as docker container (earthly-buildkitd)
2. Build 🔧
————————————————————————————————————————————————————————————————————————————————
alpine | --> Load metadata linux/amd64
+tag | --> GIT CLONE (--branch v2.30.0) https://git.kernel.org/pub/scm/git/git.git
+base | --> FROM alpine
+base | [██████████] 100% resolve docker.io/library/alpine@sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300
+tag | hint: Using 'master' as the name for the initial branch. This default branch name
+tag | hint: is subject to change. To configure the initial branch name to use in all
+tag | hint: of your new repositories, which will suppress this warning, call:
+tag | hint:
+tag | hint: git config --global init.defaultBranch <name>
+tag | hint:
+tag | hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+tag | hint: 'development'. The just-created branch can be renamed via this command:
+tag | hint:
+tag | hint: git branch -m <name>
+tag | Initialized empty Git repository in /tmp/earthly/buildkit/runc-overlayfs/snapshots/snapshots/1/fs/
+base | [██████████] 100% sha256:59bf1c3509f33515622619af21ed55bbe26d24913cedbca106468a5fb37a50c3
+base | [██████████] 100% extracting sha256:59bf1c3509f33515622619af21ed55bbe26d24913cedbca106468a5fb37a50c3
+tag | 2d9685d47a7e516281aa093bf0cddc8aafa72448 refs/tags/v2.30.0
+tag | From https://git.kernel.org/pub/scm/git/git
+tag | * [new tag] v2.30.0 -> v2.30.0
+tag | hint: Using 'master' as the name for the initial branch. This default branch name
+tag | hint: is subject to change. To configure the initial branch name to use in all
+tag | hint: of your new repositories, which will suppress this warning, call:
+tag | hint:
+tag | hint: git config --global init.defaultBranch <name>
+tag | hint:
+tag | hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+tag | hint: 'development'. The just-created branch can be renamed via this command:
+tag | hint:
+tag | hint: git branch -m <name>
+tag | Initialized empty Git repository in /tmp/earthly/buildkit/runc-overlayfs/snapshots/snapshots/3/fs/.git/
+tag | error: cannot update ref 'refs/heads/v2.30.0': trying to write non-commit object 2d9685d47a7e516281aa093bf0cddc8aafa72448 to branch 'refs/heads/v2.30.0'
+tag | From /tmp/earthly/buildkit/runc-overlayfs/snapshots/snapshots/1/fs
+tag | ! [new tag] v2.30.0 -> v2.30.0 (unable to update local ref)
+tag | * [new tag] v2.30.0 -> v2.30.0
+tag | panic: interface conversion: interface {} is syscall.WaitStatus, not unix.WaitStatus
+tag | goroutine 1 [running]:
+tag | github.com/moby/buildkit/source/git.gitMain()
+tag | /src/source/git/gitsource_unix.go:65 +0x27d
+tag | github.com/docker/docker/pkg/reexec.Init(...)
+tag | /src/vendor/github.com/docker/docker/pkg/reexec/reexec.go:26
+tag | main.init.0()
+tag | /src/cmd/buildkitd/main.go:77 +0xf6
+tag | WARN: (GIT CLONE (--branch v2.30.0) https://git.kernel.org/pub/scm/git/git.git) exit status 2
Error: build target: build main: bkClient.Build: failed to solve: exit status 2
Note 1: the --prune reset is necessary above (and below) to reliably reproduce these; if I understand correctly, GIT CLONE is a "source", thus exempt from the simpler --no-cache mechanisms.
Note 2: the current docs show usage as --branch <git-ref>, though #1211 showed --branch=<commit>; I tried my experiments with both variations and got the same results
My TL;DR; summary/interpretation/observations:
un-cached attempts to clone via commit SHA or tag name panics and fails
un-cached cloning via SHA of a signed tag still panics, but eventually results in a success
earthly sees a tag name as equivalent to a signed tag SHA, so cloning via commit SHA does work (under proper caching scenarios)
earthly does not see the same equivalence with regular tags
What does work (kind of), which I discovered on accident, is
Notice that it also paniced, with the exact same trace. But it appears that there's a hidden retry/fallback mechanism, which results in a (very long) non-shallow clone, and ultimately succeeds. At that point, the clone of the tag succeeds (when maintaining the cache), presumable due to the first-class citizenship of GIT CLONE and noticing that the signed tag SHA and the tag name are "the same".
Short preface: even though the argument key is
--branch
, the docs saying that the argument is<git-ref>
had left me hopeful that it wasn't restricted to branches. My first try at providing a commit SHA didn't work. I don't recall the exact failure. That was on an older version, and upon reading the "if you have no choice" from https://docs.earthly.dev/best-practices#git-clone-vs-run-git-clone, I went with that approach.I recently had a separate need to clone from a tag. Figuring I might have some luck getting earthly to use a tag vs. SHA, I tried again (with a version newer than my previous attempt). It fails with panic
interface conversion: interface {} is syscall.WaitStatus, not unix.WaitStatus
. When searching for existing reports, I found #1211 . The two comments suggest that both commit SHAs and tags should work. While commits and tags might technically be undocumented/unsupported behavior, the fact that tags failed with a panic (vs. validation error) is why I decided to report.To reproduce:
Earthfile:
Expectation (hope):
Actual:
Note 1: the
--prune reset
is necessary above (and below) to reliably reproduce these; if I understand correctly,GIT CLONE
is a "source", thus exempt from the simpler--no-cache
mechanisms.Note 2: the current docs show usage as
--branch <git-ref>
, though #1211 showed--branch=<commit>
; I tried my experiments with both variations and got the same resultsMy TL;DR; summary/interpretation/observations:
What does work (kind of), which I discovered on accident, is
Notice that it also paniced, with the exact same trace. But it appears that there's a hidden retry/fallback mechanism, which results in a (very long) non-shallow clone, and ultimately succeeds. At that point, the clone of the tag succeeds (when maintaining the cache), presumable due to the first-class citizenship of
GIT CLONE
and noticing that the signed tag SHA and the tag name are "the same".But:, with a regular tag:
I know there's some irony in my report about
GIT CLONE
being around cloning git's source, but the need is legitimate.)The text was updated successfully, but these errors were encountered: