util/gitutil: Full/ShortCommit(): replace git show with git rev-parse#3747
Open
jegorbunov wants to merge 2 commits intodocker:masterfrom
Open
util/gitutil: Full/ShortCommit(): replace git show with git rev-parse#3747jegorbunov wants to merge 2 commits intodocker:masterfrom
jegorbunov wants to merge 2 commits intodocker:masterfrom
Conversation
jegorbunov
force-pushed
the
gitutil-use-rev-parse-instead-of-show
branch
from
200f023 to
ba6eae3
Compare
The FullCommit and ShortCommit methods are expected to simply get the
hash of HEAD. Using `git show` for this purpose is overkill because
`git show` can have side effects that are annoying when `docker build`
runs in a CI environment:
1) CI environments (e.g. CircleCI) may use blobless clones, where the
target repository is checked out using `git clone --filter=blob:none {url}`.
2) `git show` does more than just discover the hash of a specified revision:
in general, it needs parent commits and blobs to compute the diff. When
a blobless clone is used, `git show` may try to download these additional
blobs from the remote. From my experiments, this happens even when
`--quiet` or `--no-patch` is specified.
3) If the `docker build` step runs in an environment where Git is not configured
properly to download from the remote, the step may hang indefinitely, as it did
in my case with the following prompt:
The authenticity of host 'github.com (140.82.112.3)' can't be established.
ED25519 key fingerprint is SHA256:+....
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Signed-off-by: Jegor Gorbunov <jegor.gorbunov@point-devel.com>
git rev-parse HEAD doesn't need any `--`, however, when it is called on an empty repo git returns an error: ``` fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' ``` So, it is both IsUnknownRevision and IsAmbiguousArgument. Lets simply fix the test by flipping the check: I don't see any dependency on this behavior in non-test code. Signed-off-by: Jegor Gorbunov <jegor.gorbunov@point-devel.com>
jegorbunov
force-pushed
the
gitutil-use-rev-parse-instead-of-show
branch
from
2f19caf to
758cdba
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The FullCommit and ShortCommit methods are expected to simply get the hash of HEAD. Using
git showfor this purpose is overkill becausegit showcan have side effects that are annoying whendocker buildruns in a CI environment:CI environments (e.g. CircleCI) may use blobless clones, where the target repository is checked out using
git clone --filter=blob:none {url}.git showdoes more than just discover the hash of a specified revision: in general, it needs parent commits and blobs to compute the diff. When a blobless clone is used,git showmay try to download these additional blobs from the remote. From my experiments, this happens even when--quietor--no-patchis specified.If the
docker buildstep runs in an environment where Git is not configured properly to download from the remote, the step may hang indefinitely, as it did in my case with the following prompt:The authenticity of host 'github.com (140.82.112.3)' can't be established. ED25519 key fingerprint is SHA256:+.... This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])?