Skip to content

fix vendor.mod: add hashicorp/go-multierror as direct dependency#44453

Merged
thaJeztah merged 1 commit intomoby:masterfrom
thaJeztah:fix_vendor
Nov 14, 2022
Merged

fix vendor.mod: add hashicorp/go-multierror as direct dependency#44453
thaJeztah merged 1 commit intomoby:masterfrom
thaJeztah:fix_vendor

Conversation

@thaJeztah
Copy link
Member

Starting with 2bdc7fb (#44210), the github.com/hashicorp/go-multierror module is a direct dependency.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Starting with 2bdc7fb, the
github.com/hashicorp/go-multierror module is a direct dependency.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
Copy link
Contributor

@corhere corhere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, thanks!

@thaJeztah
Copy link
Member Author

BuildKit failures are unrelated, and will be fixed in #44452. See #44452 (comment)

@thaJeztah thaJeztah merged commit 5f6b0a7 into moby:master Nov 14, 2022
@thaJeztah thaJeztah deleted the fix_vendor branch November 14, 2022 19:15
@neersighted
Copy link
Member

neersighted commented Nov 14, 2022

It looks like golang/go#27005 is what would provide a built-in fast path for this case; however, implementing something ourselves with go mod tidy && git diff-index --exit-code HEAD ought to be sufficient to prevent this scenario. I'll experiment with pushing more of the logic into vendor.sh so we can always tidy and only re-vendor when needed.

@thaJeztah
Copy link
Member Author

Thanks! Yes, mostly want to prevent doing a full vendor update (if not needed), so if there's a way to check without running the actual vendoring, that'd be nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants