-
-
Notifications
You must be signed in to change notification settings - Fork 4
Bump github.com/go-git/go-git/v5 from 5.12.0 to 5.14.0 #305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump github.com/go-git/go-git/v5 from 5.12.0 to 5.14.0 #305
Conversation
Bumps [github.com/go-git/go-git/v5](https://github.com/go-git/go-git) from 5.12.0 to 5.14.0. - [Release notes](https://github.com/go-git/go-git/releases) - [Commits](go-git/go-git@v5.12.0...v5.14.0) --- updated-dependencies: - dependency-name: github.com/go-git/go-git/v5 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the review on the previous bump PR:
I verified that the blocker bug mentioned there is still present in github.com/go-git/go-git/[email protected].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made the following statement made in the previous review:
I verified that the blocker bug mentioned there is still present in
github.com/go-git/go-git/[email protected]
It is true that the bug (go-git/go-git#1411) is still present. However, after further investigation I discovered that the original determination that go-git/go-git#1411 is a blocker for bumping github.com/go-git/go-git/v5 in libraries-repository-engine was erroneous.
Summary
It turns out that go-git/go-git#1411 is not effectively a regression for libraries-repository-engine. The reason is that the conditions under which go-git/go-git#1411 occurs would cause libraries-repository-engine to fault even without the bump.
Explanation
The conditions under which go-git/go-git#1411 occurs are:
- The repository contains a file with executable permissions.
- The the
github.com/go-git/go-git/v5.Worktree.Checkoutmethod is called. - The application is running on a Windows machine.
After bumping the github.com/go-git/go-git/v5 dependency to v5.14.0 (or v5.13.2), a call to the github.com/arduino/libraries-repository-engine/internal/libraries/gitutils.CheckoutTag function will return an error under these conditions, here:
libraries-repository-engine/internal/libraries/gitutils/gitutils.go
Lines 174 to 176 in ec0ec0c
| if err = repoTree.Checkout(&git.CheckoutOptions{Hash: *resolvedTag, Force: true}); err != nil { | |
| return err | |
| } |
However, the function will return an error under these conditions even with a version of github.com/go-git/go-git/v5 <v5.13.2. This is due to a separate bug in handling of these conditions: go-git/go-git#771. With the previous versions of github.com/go-git/go-git/v5, github.com/go-git/go-git/v5.Worktree.Checkout will not return an error, but github.com/go-git/go-git/v5.Status.IsClean returns false, this causes github.com/arduino/libraries-repository-engine/internal/libraries/gitutils.cleanRepository to return false:
| return repoStatus.IsClean(), nil |
which in turn causes github.com/arduino/libraries-repository-engine/internal/libraries/gitutils.CheckoutTag to return an error:
libraries-repository-engine/internal/libraries/gitutils/gitutils.go
Lines 178 to 190 in ec0ec0c
| // Ensure the repository is checked out to a clean state. | |
| // Because it might not succeed on the first attempt, a retry is allowed. | |
| for range [2]int{} { | |
| clean, err := cleanRepository(repoTree) | |
| if err != nil { | |
| return err | |
| } | |
| if clean { | |
| return nil | |
| } | |
| } | |
| return fmt.Errorf("failed to get repository to clean state") |
Conclusion
Since the bump does not cause an effective regression in libraries-repository-engine, there is no reason to refrain from accepting it.
Although ideally libraries-repository-engine would operate correctly under these conditions, the inability of the application to do so is not a critical defect. The reason is that the bug is specific to the Windows filesystem (which does not have the concept of executable file permissions) and the production usage of the application is exclusively on a Linux machine. So the defect could only impact contributors using a Windows machine to perform freestyle testing (the project's formal test suite does not provide coverage for these conditions).
Bumps github.com/go-git/go-git/v5 from 5.12.0 to 5.14.0.
Release notes
Sourced from github.com/go-git/go-git/v5's releases.
... (truncated)
Commits
863c621Merge pull request #1436 from pjbgf/v5-bumps2e69e81build: Bump dependenciesb2c1ec9build: Bump Go versions2c68247Merge pull request #1383 from go-git/dependabot/go_modules/github.com/ProtonM...d462c2eMerge pull request #1359 from BeChris/issue1150-v532ac23aMerge pull request #1392 from go-git/dependabot/go_modules/github.com/pjbgf/s...93e635abuild: bump github.com/pjbgf/sha1cd from 0.3.0 to 0.3.2b2bb975git: worktree_status, took into account code review remarks518ac88git: worktree_status, fix adding dot slash files to working tree (backported ...21b3150build: bump github.com/ProtonMail/go-crypto from 1.1.4 to 1.1.5Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)