Add generation of apiserver-builder executables, .deb and .rpm packages in . #150
Conversation
…ages in build/. Add VERSION file.
k8s-ci-robot
added
cncf-cla: yes
|
@pwittrock I'll have a look at your suggestions in #148. |
metmajer
changed the title
|
@pwittrock following your suggestion, I now use the following commands to build a release. I am getting the following error message from the I executed the command from the repository's root directory and I also don't see any notable difference in build-tools.sh. |
Makefile
Outdated
| .PHONY: build-apiregister-gen-linux-amd64 build-apiserver-boot-linux-amd64 build-apiserver-builder-release-linux-amd64 | ||
| build-apiregister-gen-linux-amd64 build-apiserver-boot-linux-amd64 build-apiserver-builder-release-linux-amd64: build-%-linux-amd64: | ||
| mkdir -p $(LINUX_AMD64_BUILD_BIN_DIR) | ||
| GOOS=linux GOARCH=amd64 go build -o $(LINUX_AMD64_BUILD_BIN_DIR)/$* ./cmd/$*/main.go |
There was a problem hiding this comment.
We may need to do something more than this. The tar release contains builds of the vendored code-generators + the vendored go packages.
There was a problem hiding this comment.
Take a look at the artifacts in the .tar.gz published in the release and the release cmd.
There was a problem hiding this comment.
Understood (see the comment above). The idea is then to run apiserver-builder-release to build a .tar.gz and use this to create the packages. Do you have any idea why apiserver-boot fails when I run apiserver-builder-release (again, see the comment above).
There was a problem hiding this comment.
Hm. That is weird, the release command should set the GOPATH. Looking that the code, it looks like it might be just appending the GOPATH. Perhaps if your GOPATH is already set, it won't override it. What OS are you running this on? I have only run it from a Mac.
I am going to try a fix by removing the existing GOPATH env from the exec'ed command environment if it is preset.
There was a problem hiding this comment.
I am running this on a Mac with a GOPATH set. Since you're already on it, I won't open an issue for it then. Thanks!
There was a problem hiding this comment.
Hm, that is odd. What shell are you using? I made some changes so it will prune the GOPATH from the environment when execing. Try running again now.
There was a problem hiding this comment.
Your may revert your change to GOPATH handling. The error was due to glide being missing.
|
Thanks @metmajer. I will be traveling for the next, so may be less responsive than typical, but will try to be available. |
…cts. 'make package' uses these artefacts for creating .deb and .rpm.
|
I've changed the implementation to create build artefacts using Installing these packages will make binaries end up in |
|
The |
metmajer
changed the title
|
@metmajer I don't think there is a particular reason. I was copying how the go installation is structured /usr/local/go/bin => /usr/local/apiserver-builder/bin. Where do you think the binaries should be installed? We could instead just do /usr/local/apiserver-builder. Since there are multiple binaries contained in the distribution, I am not sure we want just /usr/local/bin. |
|
I am open to anything though. |
|
@pwittrock Installing them into Appreciate your thoughts. Having the |
|
@metmajer hm, I am starting to lean toward the tar containing a folder called |
|
|
||
| .PHONY: build | ||
| build: clean ## Create release artefacts for darwin:amd64, linux:amd64 and windows:amd64. Requires etcd, glide, hg. | ||
| go run ./cmd/apiserver-builder-release/main.go vendor --version $(VERSION) |
There was a problem hiding this comment.
The preferred format of this command is to pass it a --commit flag to make sure it pulls down the apiserver-builder at the intended versions (and not whatever glide has cached)
There was a problem hiding this comment.
Can you explain how we could make use of --commit here? Which version would be expected?
There was a problem hiding this comment.
TL;DR
The most recent commit hash from the apiserver-buidler repo
The release command doesn't use the local src for building the glide.tar.gz with the vendored go code for apiserver-builder++. Instead it uses apiserver-boot (built from the local code) to start a new project, and run glide to download all of the godeps to vendor. The commit here is put in the glide.yaml file to pin the apiserver-builder vendored go libraries. This ensures that the correct version of the libraries are vendored, instead of whatever glide decides it wants to fetch (can depend on the local cache).
|
@metmajer Looks good. I will follow up on changing the release script to put the binaries in a folder called |
metmajer
changed the title
This PR creates
apiserver-builderexecutables fordarwin-amd64,linux-amd64andwindows-amd64inbuild/viamake build:Additionally, it enables the creation of
.deband.rpmpackages using jordansissel/fpm inbuild/viamake packages:The version number is now stored in
VERSIONfor better version management.Debian Package
Information
Installation
Users can install the
.debpackage either usingdpkg -i $name.deborapt-get install -f $name.deborapt install $name.deb.RPM Package
Information
With that,
.deband.rpmpackages can now be attached to a release on GitHub. If you like, I can also include the generation of source and binary.tar.gzdistributables.