Unset GO111MODULE within Gimme itself #159
Merged
Conversation
This file contains 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
Presumably when `GO111MODULE` is set in environ when calling `gimme`, it's part of generic setup to be used by the Go toolchain when building the code being CI tested and the intent is not to try to tell Go, when building from source, that it should be requiring the new Go 1.11 module semantics. Forcibly unset `GO111MODULE` in Gimme itself, but do not do anything to add this to the emitted environment variables. Without this, `gimme master` currently fails; with this change, it succeeds.
|
(Side-nudge: |
philpennock
added a commit
that referenced
this pull request
Aug 14, 2018
We already have logic to handle `GIMME_DEBUG` looking like a number and capturing more output here; just use one number higher to ask `make.bash` to be verbose. Slightly repetitive, but cleaner and easier to understand than conditional arrays or stuff which would affect shellcheck if we relied upon empty unquoted args being dropped. With this and without the #159 unset of `GO111MODULE`, invoking as `GIMME_DEBUG=3 GO111MODULE=on gimme master` reveals all the `use of internal package` complaints which show that building Go itself is incompatible with having `GO111MODULE` set in environ.
AlekSi
approved these changes
Aug 14, 2018
philpennock
added a commit
that referenced
this pull request
Aug 14, 2018
We already have logic to handle `GIMME_DEBUG` looking like a number and capturing more output from `make.bash` here; adjust condition to make it clearer which value triggers is, and also tell `make.bash` to be more verbose and get more details in the captured log. Having `make.bash -v`, before the the #159 unset of `GO111MODULE`, this facility reveals all the `use of internal package` complaints which show that building Go itself is incompatible with having `GO111MODULE` set in environ.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Presumably when
GO111MODULEis set in environ when callinggimme, it's part of generic setup to be used by the Go toolchain when building the code being CI tested and the intent is not to try to tell Go, when building from source, that it should be requiring the new Go 1.11 module semantics.Forcibly unset
GO111MODULEin Gimme itself, but do not do anything to add this to the emitted environment variables.Without this,
gimme mastercurrently fails; with this change, it succeeds.Fixes #158