Stop relying on -modfile to allow vendorization #968
Conversation
metal3-io-bot
added
the
size/S
|
This is a good catch @honza, thanks. |
|
@ardaguclu: adding LGTM is restricted to approvers and reviewers in OWNERS files. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test-integration |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hardys, s3rj1k The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
metal3-io-bot
added
the
approved
|
This is unfortunate :( the -modfile approach seemed quite elegant compared to switching directories. There is another use of |
honza
force-pushed
the
makefile-tools
branch
from
6f5730c
to
90610be
Compare
Fixed |
honza
force-pushed
the
makefile-tools
branch
from
90610be
to
b7b9e8c
Compare
metal3-io-bot
added
size/M
|
/test-integration |
honza
force-pushed
the
makefile-tools
branch
from
b7b9e8c
to
a84f02b
Compare
|
/test-integration |
honza
force-pushed
the
makefile-tools
branch
from
a84f02b
to
d573fa1
Compare
|
/test-integration |
honza
force-pushed
the
makefile-tools
branch
from
d573fa1
to
3baba91
Compare
|
/test-integration |
honza
force-pushed
the
makefile-tools
branch
from
3baba91
to
24b1b3e
Compare
|
/test-integration |
The Makefile targets we use to build our tools rely on the `-modfile` flag of the `go build` command. Unfortunately, the golang build toolchain doesn't respect the vendor directory relative to the `go.mod` file specified by `-modfile`, and instead uses the vendor directory relative to the current working directory. Since each subdirectory in this repository that contains a `go.mod` file needs to have its own vendor directory in order to be built in vendorized scenarios, relying on `-modfile` doesn't work. The patch modifies the affected Makefile targets to instead change to the directory of the tool being built instead of using the `-modfile` flag. This makes vendorization possible in downstream environments. Finally, for consistency, we start building the kustomize tool in the same way as controller-gen, and golangci-lint.
honza
force-pushed
the
makefile-tools
branch
from
24b1b3e
to
f2616f9
Compare
|
/test-integration |
|
/lgtm |
The Makefile targets we use to build our tools rely on the
-modfileflag of the
go buildcommand. Unfortunately, the golang buildtoolchain doesn't respect the vendor directory relative to the
go.modfile specified by
-modfile, and instead uses the vendor directoryrelative to the current working directory. Since each subdirectory in
this repository that contains a
go.modfile needs to have its ownvendor directory in order to be built in vendorized scenarios, relying
on
-modfiledoesn't work.The patch modifies the affected Makefile targets to instead change to
the directory of the tool being built instead of using the
-modfileflag. This makes vendorization possible in downstream environments.
Finally, for consistency, we start building the kustomize tool in the
same way as controller-gen, and golangci-lint.