Set the values of major and minor version based on the output of the
`git describe` command, which uses annotated tags as source of
versioning information.
Minor will get a "+" appended whenever the annotated tag does not match
the tree exactly (including when the tree is dirty.) So that only
official releases will have a "bare" minor version, all others will have
a "+" to indicate the binaries contain changes from the released version
in minor.
(This is similar to how versions of development builds of the Linux
kernel work.)
Tested:
- With no annotated tags:
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"0", Minor:"1+", GitVersion:"v0.1+", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"clean"}
- Tagging current version on a clean git tree:
$ git tag -a -m 'Test tag v2.3' v2.3
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"2", Minor:"3", GitVersion:"v2.3", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"clean"}
- Tagging current version on a dirty git tree:
$ git tag -a -m 'Test tag v2.3' v2.3
$ touch test.txt # this is enough to mark the tree as dirty
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"2", Minor:"3+", GitVersion:"v2.3-dirty", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"dirty"}
- Tagging a previous version on a clean tree:
$ git tag -a -m 'Test tag v2.3' v2.3 HEAD~5
$ hack/build-go.sh
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"2", Minor:"3+", GitVersion:"v2.3-6-g7d29873bdee87e", GitCommit:"7d29873bdee87efacaace30ab3602297cacf1b4f", GitTreeState:"clean"}
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Ensure the output of `git describe` will include the `-dirty` suffix
when building on a tree with modified files in it.
Tested:
- ...
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This avoids some conflict with the built-in `flag` module in Go. The
module was already being renamed to `verflag` on import anyways, so we
might as well just call it that.
Tested:
- hack/build-go.sh and ran the resulting binaries with -version args.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This can be helpful to print the internal fields of the version
information that will contain more details about the git tree than the
short -version output will.
Tested:
- Tested getting the raw version:
$ _output/go/bin/kubecfg -version=raw
version.Info{Major:"0", Minor:"1+", GitVersion:"v2.2.1-33-gdc4becd9765393", GitCommit:"dc4becd9765393fa05a3eb06f6af9e00068fe0c5", GitTreeState:"dirty"}
- Tested getting the simple version:
$ _output/go/bin/kubecfg -version
Kubernetes version 0.1+, build dc4becd976
- Tested getting the help output:
$ _output/go/bin/kubecfg 2>&1 | grep -- -version
-version=false: Print version information and quit
- Made sure -version=true and -version=false works, that -version with
an invalid argument works as expected (prints usage help) and that
-version followed by space will not try to use the next word as its
argument (i.e. `-version raw` prints the version but not the raw one.)
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
The `systemctl enable` command ordinarily prints the `ln` command used
to enable the unit to stderr, but that's not ideal in the vagrant setup
because it gets printed in red, which should be reserved for errors, but
it's not a real error.
Set an environment variable to raise the log level to prevent `info`
messages from being printed to stderr (as they are not actually errors.)
I looked into the `systemctl` calls happening from the Salt setup script
to understand why they were not going to stderr, and it turns out the
Salt script will redirect all messages to stdout so they will all be
green regardless...
Tested:
- Started a fresh Vagrant cluster, confirmed no red messages in output
when creating the cluster successfully. Successfully started nginx
through Kubernetes using cluster/kubecfg.sh.
- Confirmed that the salt-api service was up after `vagrant up`:
$ vagrant ssh master -c 'systemctl status salt-api.service'
salt-api.service - The Salt API
Loaded: loaded (/usr/lib/systemd/system/salt-api.service; enabled)
Active: active (running) since Fri 2014-08-29 23:19:47 UTC; 11min ago
Main PID: 2090 (salt-api)
CGroup: /system.slice/salt-api.service
+-2090 /usr/bin/python /usr/bin/salt-api
+-2110 /usr/bin/python /usr/bin/salt-api
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This is a very simple Makefile that just passes through to the current hack/*
scripts. Only "make", "make test", and "make clean" are supported for now.
Clayton Coleman