mirror of https://github.com/k3s-io/k3s
Eric Tune
parent
3f52a97052
commit
2ce16acd67
|
|
@ -21,7 +21,7 @@ Follow either of the two links above to access the appropriate CLA and instructi
|
|||
|
||||
## Protocols for Collaborative Development
|
||||
|
||||
Please read [this doc](docs/collab.md) for information on how we're running development for the project.
|
||||
Please read [this doc](docs/devel/collab.md) for information on how we're running development for the project.
|
||||
|
||||
## Adding dependencies
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ Check out examples of Kubernetes in action, and community projects in the larger
|
|||
* [Example of dynamic updates](examples/update-demo/README.md)
|
||||
* [Cluster monitoring with heapster and cAdvisor](https://github.com/GoogleCloudPlatform/heapster)
|
||||
* [Community projects](https://github.com/GoogleCloudPlatform/kubernetes/wiki/Kubernetes-Community)
|
||||
* [Development guide](docs/development.md)
|
||||
* [Development guide](docs/devel/development.md)
|
||||
|
||||
Or fork and start hacking!
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
# On Collaborative Development
|
||||
|
||||
Kubernetes is open source, but many of the people working on it do so as their day job. In order to avoid forcing people to be "at work" effectively 24/7, we want to establish some semi-formal protocols around development. Hopefully these rules make things go more smoothly. If you find that this is not the case, please complain loudly.
|
||||
|
||||
## Patches welcome
|
||||
|
||||
First and foremost: as a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a PR.
|
||||
|
||||
## Timezones and calendars
|
||||
|
||||
For the time being, most of the people working on this project are in the US and on Pacific time. Any times mentioned henceforth will refer to this timezone. Any references to "work days" will refer to the US calendar.
|
||||
|
||||
## Code reviews
|
||||
|
||||
All changes must be code reviewed. For non-maintainers this is obvious, since you can't commit anyway. But even for maintainers, we want all changes to get at least one review, preferably from someone who knows the areas the change touches. For non-trivial changes we may want two reviewers. The primary reviewer will make this decision and nominate a second reviewer, if needed. Except for trivial changes, PRs should sit for at least a 2 hours to allow for wider review.
|
||||
|
||||
Most PRs will find reviewers organically. If a maintainer intends to be the primary reviewer of a PR they should set themselves as the assignee on GitHub and say so in a reply to the PR. Only the primary reviewer of a change should actually do the merge, except in rare cases (e.g. they are unavailable in a reasonable timeframe).
|
||||
|
||||
If a PR has gone 2 work days without an owner emerging, please poke the PR thread and ask for a reviewer to be assigned.
|
||||
|
||||
Except for rare cases, such as trivial changes (e.g. typos, comments) or emergencies (e.g. broken builds), maintainers should not merge their own changes.
|
||||
|
||||
Expect reviewers to request that you avoid [common go style mistakes](https://code.google.com/p/go-wiki/wiki/CodeReviewComments) in your PRs.
|
||||
|
||||
## Assigned reviews
|
||||
|
||||
Maintainers can assign reviews to other maintainers, when appropriate. The assignee becomes the shepherd for that PR and is responsible for merging the PR once they are satisfied with it or else closing it. The assignee might request reviews from non-maintainers.
|
||||
|
||||
## Merge hours
|
||||
|
||||
Maintainers will do merges between the hours of 7:00 am Monday and 7:00 pm (19:00h) Friday. PRs that arrive over the weekend or on holidays will only be merged if there is a very good reason for it and if the code review requirements have been met.
|
||||
|
||||
There may be discussion an even approvals granted outside of the above hours, but merges will generally be deferred.
|
||||
|
||||
## Holds
|
||||
|
||||
Any maintainer or core contributor who wants to review a PR but does not have time immediately may put a hold on a PR simply by saying so on the PR discussion and offering an ETA measured in single-digit days at most. Any PR that has a hold shall not be merged until the person who requested the hold acks the review, withdraws their hold, or is overruled by a preponderance of maintainers.
|
||||
|
|
@ -0,0 +1,179 @@
|
|||
# Development Guide
|
||||
|
||||
# Releases and Official Builds
|
||||
|
||||
Official releases are built in Docker containers. Details are [here](build/README.md). You can do simple builds and development with just a local Docker installation. If want to build go locally outside of docker, please continue below.
|
||||
|
||||
## Go development environment
|
||||
|
||||
Kubernetes is written in [Go](http://golang.org) programming language. If you haven't set up Go development environment, please follow [this instruction](http://golang.org/doc/code.html) to install go tool and set up GOPATH. Ensure your version of Go is at least 1.3.
|
||||
|
||||
## Put kubernetes into GOPATH
|
||||
|
||||
We highly recommend to put kubernetes' code into your GOPATH. For example, the following commands will download kubernetes' code under the current user's GOPATH (Assuming there's only one directory in GOPATH.):
|
||||
|
||||
```
|
||||
$ echo $GOPATH
|
||||
/home/user/goproj
|
||||
$ mkdir -p $GOPATH/src/github.com/GoogleCloudPlatform/
|
||||
$ cd $GOPATH/src/github.com/GoogleCloudPlatform/
|
||||
$ git clone git@github.com:GoogleCloudPlatform/kubernetes.git
|
||||
```
|
||||
|
||||
The commands above will not work if there are more than one directory in ``$GOPATH``.
|
||||
|
||||
(Obviously, clone your own fork of Kubernetes if you plan to do development.)
|
||||
|
||||
## godep and dependency management
|
||||
|
||||
Kubernetes uses [godep](https://github.com/tools/godep) to manage dependencies. It is not strictly required for building Kubernetes but it is required when managing dependencies under the Godeps/ tree, and is required by a number of the build and test scripts. Please make sure that ``godep`` is installed and in your ``$PATH``.
|
||||
|
||||
### Installing godep
|
||||
There are many ways to build and host go binaries. Here is an easy way to get utilities like ```godep``` installed:
|
||||
|
||||
1. Ensure that [mercurial](http://mercurial.selenic.com/wiki/Download) is installed on your system. (some of godep's dependencies use the mercurial
|
||||
source control system). Use ```apt-get install mercurial``` or ```yum install mercurial``` on Linux, or [brew.sh](http://brew.sh) on OS X, or download
|
||||
directly from mercurial.
|
||||
2. Create a new GOPATH for your tools and install godep:
|
||||
```
|
||||
export GOPATH=$HOME/go-tools
|
||||
mkdir -p $GOPATH
|
||||
go get github.com/tools/godep
|
||||
```
|
||||
|
||||
3. Add $GOPATH/bin to your path. Typically you'd add this to your ~/.profile:
|
||||
```
|
||||
export GOPATH=$HOME/go-tools
|
||||
export PATH=$PATH:$GOPATH/bin
|
||||
```
|
||||
|
||||
### Using godep
|
||||
Here is a quick summary of `godep`. `godep` helps manage third party dependencies by copying known versions into Godeps/_workspace. You can use `godep` in three ways:
|
||||
|
||||
1. Use `godep` to call your `go` commands. For example: `godep go test ./...`
|
||||
2. Use `godep` to modify your `$GOPATH` so that other tools know where to find the dependencies. Specifically: `export GOPATH=$GOPATH:$(godep path)`
|
||||
3. Use `godep` to copy the saved versions of packages into your `$GOPATH`. This is done with `godep restore`.
|
||||
|
||||
We recommend using options #1 or #2.
|
||||
|
||||
## Hooks
|
||||
|
||||
Before committing any changes, please link/copy these hooks into your .git
|
||||
directory. This will keep you from accidentally committing non-gofmt'd go code.
|
||||
|
||||
```
|
||||
cd kubernetes
|
||||
ln -s hooks/prepare-commit-msg .git/hooks/prepare-commit-msg
|
||||
ln -s hooks/commit-msg .git/hooks/commit-msg
|
||||
```
|
||||
|
||||
## Unit tests
|
||||
|
||||
```
|
||||
cd kubernetes
|
||||
hack/test-go.sh
|
||||
```
|
||||
|
||||
Alternatively, you could also run:
|
||||
|
||||
```
|
||||
cd kubernetes
|
||||
godep go test ./...
|
||||
```
|
||||
|
||||
If you only want to run unit tests in one package, you could run ``godep go test`` under the package directory. For example, the following commands will run all unit tests in package kubelet:
|
||||
|
||||
```
|
||||
$ cd kubernetes # step into kubernetes' directory.
|
||||
$ cd pkg/kubelet
|
||||
$ godep go test
|
||||
# some output from unit tests
|
||||
PASS
|
||||
ok github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet 0.317s
|
||||
```
|
||||
|
||||
## Coverage
|
||||
```
|
||||
cd kubernetes
|
||||
godep go tool cover -html=target/c.out
|
||||
```
|
||||
|
||||
## Integration tests
|
||||
|
||||
You need an etcd somewhere in your PATH. To install etcd, run:
|
||||
|
||||
```
|
||||
cd kubernetes
|
||||
hack/install-etcd.sh
|
||||
sudo ln -s $(pwd)/third_party/etcd/bin/etcd /usr/bin/etcd
|
||||
```
|
||||
|
||||
```
|
||||
cd kubernetes
|
||||
hack/test-integration.sh
|
||||
```
|
||||
|
||||
## End-to-End tests
|
||||
|
||||
You can run an end-to-end test which will bring up a master and two minions, perform some tests, and then tear everything down. Make sure you have followed the getting started steps for your chosen cloud platform (which might involve changing the `KUBERNETES_PROVIDER` environment variable to something other than "gce".
|
||||
```
|
||||
cd kubernetes
|
||||
hack/e2e-test.sh
|
||||
```
|
||||
|
||||
Pressing control-C should result in an orderly shutdown but if something goes wrong and you still have some VMs running you can force a cleanup with the magical incantation:
|
||||
```
|
||||
hack/e2e-test.sh 1 1 1
|
||||
```
|
||||
|
||||
## Testing out flaky tests
|
||||
[Instructions here](docs/devel/flaky-tests.md)
|
||||
|
||||
## Add/Update dependencies
|
||||
|
||||
Kubernetes uses [godep](https://github.com/tools/godep) to manage dependencies. To add or update a package, please follow the instructions on [godep's document](https://github.com/tools/godep).
|
||||
|
||||
To add a new package ``foo/bar``:
|
||||
|
||||
- Make sure the kubernetes' root directory is in $GOPATH/github.com/GoogleCloudPlatform/kubernetes
|
||||
- Run ``godep restore`` to make sure you have all dependancies pulled.
|
||||
- Download foo/bar into the first directory in GOPATH: ``go get foo/bar``.
|
||||
- Change code in kubernetes to use ``foo/bar``.
|
||||
- Run ``godep save ./...`` under kubernetes' root directory.
|
||||
|
||||
To update a package ``foo/bar``:
|
||||
|
||||
- Make sure the kubernetes' root directory is in $GOPATH/github.com/GoogleCloudPlatform/kubernetes
|
||||
- Run ``godep restore`` to make sure you have all dependancies pulled.
|
||||
- Update the package with ``go get -u foo/bar``.
|
||||
- Change code in kubernetes accordingly if necessary.
|
||||
- Run ``godep update foo/bar`` under kubernetes' root directory.
|
||||
|
||||
## Keeping your development fork in sync
|
||||
|
||||
One time after cloning your forked repo:
|
||||
|
||||
```
|
||||
git remote add upstream https://github.com/GoogleCloudPlatform/kubernetes.git
|
||||
```
|
||||
|
||||
Then each time you want to sync to upstream:
|
||||
|
||||
```
|
||||
git fetch upstream
|
||||
git rebase upstream/master
|
||||
```
|
||||
|
||||
## Regenerating the API documentation
|
||||
|
||||
```
|
||||
cd kubernetes/api
|
||||
sudo docker build -t kubernetes/raml2html .
|
||||
sudo docker run --name="docgen" kubernetes/raml2html
|
||||
sudo docker cp docgen:/data/kubernetes.html .
|
||||
```
|
||||
|
||||
View the API documentation using htmlpreview (works on your fork, too):
|
||||
```
|
||||
http://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/blob/master/api/kubernetes.html
|
||||
```
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
# Hunting flaky tests in Kubernetes
|
||||
Sometimes unit tests are flaky. This means that due to (usually) race conditions, they will occasionally fail, even though most of the time they pass.
|
||||
|
||||
We have a goal of 99.9% flake free tests. This means that there is only one flake in one thousand runs of a test.
|
||||
|
||||
Running a test 1000 times on your own machine can be tedious and time consuming. Fortunately, there is a better way to achieve this using Kubernetes.
|
||||
|
||||
_Note: these instructions are mildly hacky for now, as we get run once semantics and logging they will get better_
|
||||
|
||||
There is a testing image ```brendanburns/flake``` up on the docker hub. We will use this image to test our fix.
|
||||
|
||||
Create a replication controller with the following config:
|
||||
```yaml
|
||||
id: flakeController
|
||||
desiredState:
|
||||
replicas: 24
|
||||
replicaSelector:
|
||||
name: flake
|
||||
podTemplate:
|
||||
desiredState:
|
||||
manifest:
|
||||
version: v1beta1
|
||||
id: ""
|
||||
volumes: []
|
||||
containers:
|
||||
- name: flake
|
||||
image: brendanburns/flake
|
||||
env:
|
||||
- name: TEST_PACKAGE
|
||||
value: pkg/tools
|
||||
- name: REPO_SPEC
|
||||
value: https://github.com/GoogleCloudPlatform/kubernetes
|
||||
restartpolicy: {}
|
||||
labels:
|
||||
name: flake
|
||||
labels:
|
||||
name: flake
|
||||
```
|
||||
|
||||
```./cluster/kubecfg.sh -c controller.yaml create replicaControllers```
|
||||
|
||||
This will spin up 100 instances of the test. They will run to completion, then exit, the kubelet will restart them, eventually you will have sufficient
|
||||
runs for your purposes, and you can stop the replication controller:
|
||||
|
||||
```sh
|
||||
./cluster/kubecfg.sh stop flakeController
|
||||
./cluster/kubecfg.sh rm flakeController
|
||||
```
|
||||
|
||||
Now examine the machines with ```docker ps -a``` and look for tasks that exited with non-zero exit codes (ignore those that exited -1, since that's what happens when you stop the replica controller)
|
||||
|
||||
Happy flake hunting!
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
// Build it with:
|
||||
// $ dot -Tsvg releasing.dot >releasing.svg
|
||||
|
||||
digraph tagged_release {
|
||||
size = "5,5"
|
||||
// Arrows go up.
|
||||
rankdir = BT
|
||||
subgraph left {
|
||||
// Group the left nodes together.
|
||||
ci012abc -> pr101 -> ci345cde -> pr102
|
||||
style = invis
|
||||
}
|
||||
subgraph right {
|
||||
// Group the right nodes together.
|
||||
version_commit -> dev_commit
|
||||
style = invis
|
||||
}
|
||||
{ // Align the version commit and the info about it.
|
||||
rank = same
|
||||
// Align them with pr101
|
||||
pr101
|
||||
version_commit
|
||||
// release_info shows the change in the commit.
|
||||
release_info
|
||||
}
|
||||
{ // Align the dev commit and the info about it.
|
||||
rank = same
|
||||
// Align them with 345cde
|
||||
ci345cde
|
||||
dev_commit
|
||||
dev_info
|
||||
}
|
||||
// Join the nodes from subgraph left.
|
||||
pr99 -> ci012abc
|
||||
pr102 -> pr100
|
||||
// Do the version node.
|
||||
pr99 -> version_commit
|
||||
dev_commit -> pr100
|
||||
tag -> version_commit
|
||||
pr99 [
|
||||
label = "Merge PR #99"
|
||||
shape = box
|
||||
fillcolor = "#ccccff"
|
||||
style = "filled"
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
ci012abc [
|
||||
label = "012abc"
|
||||
shape = circle
|
||||
fillcolor = "#ffffcc"
|
||||
style = "filled"
|
||||
fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace"
|
||||
];
|
||||
pr101 [
|
||||
label = "Merge PR #101"
|
||||
shape = box
|
||||
fillcolor = "#ccccff"
|
||||
style = "filled"
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
ci345cde [
|
||||
label = "345cde"
|
||||
shape = circle
|
||||
fillcolor = "#ffffcc"
|
||||
style = "filled"
|
||||
fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace"
|
||||
];
|
||||
pr102 [
|
||||
label = "Merge PR #102"
|
||||
shape = box
|
||||
fillcolor = "#ccccff"
|
||||
style = "filled"
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
version_commit [
|
||||
label = "678fed"
|
||||
shape = circle
|
||||
fillcolor = "#ccffcc"
|
||||
style = "filled"
|
||||
fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace"
|
||||
];
|
||||
dev_commit [
|
||||
label = "456dcb"
|
||||
shape = circle
|
||||
fillcolor = "#ffffcc"
|
||||
style = "filled"
|
||||
fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace"
|
||||
];
|
||||
pr100 [
|
||||
label = "Merge PR #100"
|
||||
shape = box
|
||||
fillcolor = "#ccccff"
|
||||
style = "filled"
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
release_info [
|
||||
label = "pkg/version/base.go:\ngitVersion = \"v0.5\";"
|
||||
shape = none
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
dev_info [
|
||||
label = "pkg/version/base.go:\ngitVersion = \"v0.5-dev\";"
|
||||
shape = none
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
tag [
|
||||
label = "$ git tag -a v0.5"
|
||||
fillcolor = "#ffcccc"
|
||||
style = "filled"
|
||||
fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif"
|
||||
];
|
||||
}
|
||||
|
||||
|
|
@ -0,0 +1,152 @@
|
|||
# Releasing Kubernetes
|
||||
|
||||
This document explains how to create a Kubernetes release (as in version) and
|
||||
how the version information gets embedded into the built binaries.
|
||||
|
||||
## Origin of the Sources
|
||||
|
||||
Kubernetes may be built from either a git tree (using `hack/build-go.sh`) or
|
||||
from a tarball (using either `hack/build-go.sh` or `go install`) or directly by
|
||||
the Go native build system (using `go get`).
|
||||
|
||||
When building from git, we want to be able to insert specific information about
|
||||
the build tree at build time. In particular, we want to use the output of `git
|
||||
describe` to generate the version of Kubernetes and the status of the build
|
||||
tree (add a `-dirty` prefix if the tree was modified.)
|
||||
|
||||
When building from a tarball or using the Go build system, we will not have
|
||||
access to the information about the git tree, but we still want to be able to
|
||||
tell whether this build corresponds to an exact release (e.g. v0.3) or is
|
||||
between releases (e.g. at some point in development between v0.3 and v0.4).
|
||||
|
||||
## Version Number Format
|
||||
|
||||
In order to account for these use cases, there are some specific formats that
|
||||
may end up representing the Kubernetes version. Here are a few examples:
|
||||
|
||||
- **v0.5**: This is official version 0.5 and this version will only be used
|
||||
when building from a clean git tree at the v0.5 git tag, or from a tree
|
||||
extracted from the tarball corresponding to that specific release.
|
||||
- **v0.5-15-g0123abcd4567**: This is the `git describe` output and it indicates
|
||||
that we are 15 commits past the v0.5 release and that the SHA1 of the commit
|
||||
where the binaries were built was `0123abcd4567`. It is only possible to have
|
||||
this level of detail in the version information when building from git, not
|
||||
when building from a tarball.
|
||||
- **v0.5-15-g0123abcd4567-dirty** or **v0.5-dirty**: The extra `-dirty` prefix
|
||||
means that the tree had local modifications or untracked files at the time of
|
||||
the build, so there's no guarantee that the source code matches exactly the
|
||||
state of the tree at the `0123abcd4567` commit or at the `v0.5` git tag
|
||||
(resp.)
|
||||
- **v0.5-dev**: This means we are building from a tarball or using `go get` or,
|
||||
if we have a git tree, we are using `go install` directly, so it is not
|
||||
possible to inject the git version into the build information. Additionally,
|
||||
this is not an official release, so the `-dev` prefix indicates that the
|
||||
version we are building is after `v0.5` but before `v0.6`. (There is actually
|
||||
an exception where a commit with `v0.5-dev` is not present on `v0.6`, see
|
||||
later for details.)
|
||||
|
||||
## Injecting Version into Binaries
|
||||
|
||||
In order to cover the different build cases, we start by providing information
|
||||
that can be used when using only Go build tools or when we do not have the git
|
||||
version information available.
|
||||
|
||||
To be able to provide a meaningful version in those cases, we set the contents
|
||||
of variables in a Go source file that will be used when no overrides are
|
||||
present.
|
||||
|
||||
We are using `pkg/version/base.go` as the source of versioning in absence of
|
||||
information from git. Here is a sample of that file's contents:
|
||||
|
||||
```
|
||||
var (
|
||||
gitVersion string = "v0.4-dev" // version from git, output of $(git describe)
|
||||
gitCommit string = "" // sha1 from git, output of $(git rev-parse HEAD)
|
||||
)
|
||||
```
|
||||
|
||||
This means a build with `go install` or `go get` or a build from a tarball will
|
||||
yield binaries that will identify themselves as `v0.4-dev` and will not be able
|
||||
to provide you with a SHA1.
|
||||
|
||||
To add the extra versioning information when building from git, the
|
||||
`hack/build-go.sh` script will gather that information (using `git describe` and
|
||||
`git rev-parse`) and then create a `-ldflags` string to pass to `go install` and
|
||||
tell the Go linker to override the contents of those variables at build time. It
|
||||
can, for instance, tell it to override `gitVersion` and set it to
|
||||
`v0.4-13-g4567bcdef6789-dirty` and set `gitCommit` to `4567bcdef6789...` which
|
||||
is the complete SHA1 of the (dirty) tree used at build time.
|
||||
|
||||
## Handling Official Versions
|
||||
|
||||
Handling official versions from git is easy, as long as there is an annotated
|
||||
git tag pointing to a specific version then `git describe` will return that tag
|
||||
exactly which will match the idea of an official version (e.g. `v0.5`).
|
||||
|
||||
Handling it on tarballs is a bit harder since the exact version string must be
|
||||
present in `pkg/version/base.go` for it to get embedded into the binaries. But
|
||||
simply creating a commit with `v0.5` on its own would mean that the commits
|
||||
coming after it would also get the `v0.5` version when built from tarball or `go
|
||||
get` while in fact they do not match `v0.5` (the one that was tagged) exactly.
|
||||
|
||||
To handle that case, creating a new release should involve creating two adjacent
|
||||
commits where the first of them will set the version to `v0.5` and the second
|
||||
will set it to `v0.5-dev`. In that case, even in the presence of merges, there
|
||||
will be a single comit where the exact `v0.5` version will be used and all
|
||||
others around it will either have `v0.4-dev` or `v0.5-dev`.
|
||||
|
||||
The diagram below illustrates it.
|
||||
|
||||
|
||||
|
||||
After working on `v0.4-dev` and merging PR 99 we decide it is time to release
|
||||
`v0.5`. So we start a new branch, create one commit to update
|
||||
`pkg/version/base.go` to include `gitVersion = "v0.5"` and `git commit` it.
|
||||
|
||||
We test it and make sure everything is working as expected.
|
||||
|
||||
Before sending a PR for it, we create a second commit on that same branch,
|
||||
updating `pkg/version/base.go` to include `gitVersion = "v0.5-dev"`. That will
|
||||
ensure that further builds (from tarball or `go install`) on that tree will
|
||||
always include the `-dev` prefix and will not have a `v0.5` version (since they
|
||||
do not match the official `v0.5` exactly.)
|
||||
|
||||
We then send PR 100 with both commits in it.
|
||||
|
||||
Once the PR is accepted, we can use `git tag -a` to create an annotated tag
|
||||
*pointing to the one commit* that has `v0.5` in `pkg/version/base.go` and push
|
||||
it to GitHub. (Unfortunately GitHub tags/releases are not annotated tags, so
|
||||
this needs to be done from a git client and pushed to GitHub using SSH.)
|
||||
|
||||
## Parallel Commits
|
||||
|
||||
While we are working on releasing `v0.5`, other development takes place and
|
||||
other PRs get merged. For instance, in the example above, PRs 101 and 102 get
|
||||
merged to the master branch before the versioning PR gets merged.
|
||||
|
||||
This is not a problem, it is only slightly inaccurate that checking out the tree
|
||||
at commit `012abc` or commit `345cde` or at the commit of the merges of PR 101
|
||||
or 102 will yield a version of `v0.4-dev` *but* those commits are not present in
|
||||
`v0.5`.
|
||||
|
||||
In that sense, there is a small window in which commits will get a
|
||||
`v0.4-dev` or `v0.4-N-gXXX` label and while they're indeed later than `v0.4`
|
||||
but they are not really before `v0.5` in that `v0.5` does not contain those
|
||||
commits.
|
||||
|
||||
Unfortunately, there is not much we can do about it. On the other hand, other
|
||||
projects seem to live with that and it does not really become a large problem.
|
||||
|
||||
As an example, Docker commit a327d9b91edf has a `v1.1.1-N-gXXX` label but it is
|
||||
not present in Docker `v1.2.0`:
|
||||
|
||||
```
|
||||
$ git describe a327d9b91edf
|
||||
v1.1.1-822-ga327d9b91edf
|
||||
|
||||
$ git log --oneline v1.2.0..a327d9b91edf
|
||||
a327d9b91edf Fix data space reporting from Kb/Mb to KB/MB
|
||||
|
||||
(Non-empty output here means the commit is not present on v1.2.0.)
|
||||
```
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
|
|
@ -0,0 +1,113 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
|
||||
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<!-- Generated by graphviz version 2.36.0 (20140111.2315)
|
||||
-->
|
||||
<!-- Title: tagged_release Pages: 1 -->
|
||||
<svg width="257pt" height="360pt"
|
||||
viewBox="0.00 0.00 257.33 360.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g id="graph0" class="graph" transform="scale(0.649819 0.649819) rotate(0) translate(4 550)">
|
||||
<title>tagged_release</title>
|
||||
<polygon fill="white" stroke="none" points="-4,4 -4,-550 392,-550 392,4 -4,4"/>
|
||||
<!-- ci012abc -->
|
||||
<g id="node1" class="node"><title>ci012abc</title>
|
||||
<ellipse fill="#ffffcc" stroke="black" cx="56" cy="-115" rx="42.7926" ry="42.7926"/>
|
||||
<text text-anchor="middle" x="56" y="-111.3" font-family="Consolas, Liberation Mono, Menlo, Courier, monospace" font-size="14.00">012abc</text>
|
||||
</g>
|
||||
<!-- pr101 -->
|
||||
<g id="node2" class="node"><title>pr101</title>
|
||||
<polygon fill="#ccccff" stroke="black" points="112,-255 0,-255 0,-219 112,-219 112,-255"/>
|
||||
<text text-anchor="middle" x="56" y="-233.3" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">Merge PR #101</text>
|
||||
</g>
|
||||
<!-- ci012abc->pr101 -->
|
||||
<g id="edge1" class="edge"><title>ci012abc->pr101</title>
|
||||
<path fill="none" stroke="black" d="M56,-157.97C56,-174.83 56,-193.784 56,-208.789"/>
|
||||
<polygon fill="black" stroke="black" points="52.5001,-208.93 56,-218.93 59.5001,-208.93 52.5001,-208.93"/>
|
||||
</g>
|
||||
<!-- ci345cde -->
|
||||
<g id="node3" class="node"><title>ci345cde</title>
|
||||
<ellipse fill="#ffffcc" stroke="black" cx="62" cy="-359" rx="42.7926" ry="42.7926"/>
|
||||
<text text-anchor="middle" x="62" y="-355.3" font-family="Consolas, Liberation Mono, Menlo, Courier, monospace" font-size="14.00">345cde</text>
|
||||
</g>
|
||||
<!-- pr101->ci345cde -->
|
||||
<g id="edge2" class="edge"><title>pr101->ci345cde</title>
|
||||
<path fill="none" stroke="black" d="M56.8597,-255.193C57.5237,-268.473 58.4796,-287.592 59.3874,-305.748"/>
|
||||
<polygon fill="black" stroke="black" points="55.904,-306.17 59.8991,-315.982 62.8953,-305.82 55.904,-306.17"/>
|
||||
</g>
|
||||
<!-- pr102 -->
|
||||
<g id="node4" class="node"><title>pr102</title>
|
||||
<polygon fill="#ccccff" stroke="black" points="129,-474 17,-474 17,-438 129,-438 129,-474"/>
|
||||
<text text-anchor="middle" x="73" y="-452.3" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">Merge PR #102</text>
|
||||
</g>
|
||||
<!-- ci345cde->pr102 -->
|
||||
<g id="edge3" class="edge"><title>ci345cde->pr102</title>
|
||||
<path fill="none" stroke="black" d="M66.8248,-401.668C67.8523,-410.542 68.9117,-419.692 69.8567,-427.853"/>
|
||||
<polygon fill="black" stroke="black" points="66.3936,-428.375 71.0207,-437.906 73.3472,-427.57 66.3936,-428.375"/>
|
||||
</g>
|
||||
<!-- pr100 -->
|
||||
<g id="node10" class="node"><title>pr100</title>
|
||||
<polygon fill="#ccccff" stroke="black" points="174,-546 62,-546 62,-510 174,-510 174,-546"/>
|
||||
<text text-anchor="middle" x="118" y="-524.3" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">Merge PR #100</text>
|
||||
</g>
|
||||
<!-- pr102->pr100 -->
|
||||
<g id="edge6" class="edge"><title>pr102->pr100</title>
|
||||
<path fill="none" stroke="black" d="M84.1236,-474.303C89.355,-482.441 95.6999,-492.311 101.478,-501.299"/>
|
||||
<polygon fill="black" stroke="black" points="98.6526,-503.377 107.004,-509.896 104.541,-499.591 98.6526,-503.377"/>
|
||||
</g>
|
||||
<!-- version_commit -->
|
||||
<g id="node5" class="node"><title>version_commit</title>
|
||||
<ellipse fill="#ccffcc" stroke="black" cx="173" cy="-237" rx="42.7926" ry="42.7926"/>
|
||||
<text text-anchor="middle" x="173" y="-233.3" font-family="Consolas, Liberation Mono, Menlo, Courier, monospace" font-size="14.00">678fed</text>
|
||||
</g>
|
||||
<!-- dev_commit -->
|
||||
<g id="node6" class="node"><title>dev_commit</title>
|
||||
<ellipse fill="#ffffcc" stroke="black" cx="169" cy="-359" rx="42.7926" ry="42.7926"/>
|
||||
<text text-anchor="middle" x="169" y="-355.3" font-family="Consolas, Liberation Mono, Menlo, Courier, monospace" font-size="14.00">456dcb</text>
|
||||
</g>
|
||||
<!-- version_commit->dev_commit -->
|
||||
<g id="edge4" class="edge"><title>version_commit->dev_commit</title>
|
||||
<path fill="none" stroke="black" d="M171.601,-279.97C171.322,-288.326 171.027,-297.195 170.739,-305.844"/>
|
||||
<polygon fill="black" stroke="black" points="167.24,-305.74 170.405,-315.851 174.236,-305.973 167.24,-305.74"/>
|
||||
</g>
|
||||
<!-- dev_commit->pr100 -->
|
||||
<g id="edge8" class="edge"><title>dev_commit->pr100</title>
|
||||
<path fill="none" stroke="black" d="M158.36,-400.568C152.438,-422.433 144.719,-449.815 137,-474 134.253,-482.606 131.013,-491.906 127.994,-500.278"/>
|
||||
<polygon fill="black" stroke="black" points="124.616,-499.325 124.47,-509.919 131.191,-501.729 124.616,-499.325"/>
|
||||
</g>
|
||||
<!-- release_info -->
|
||||
<g id="node7" class="node"><title>release_info</title>
|
||||
<text text-anchor="middle" x="304" y="-240.8" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">pkg/version/base.go:</text>
|
||||
<text text-anchor="middle" x="304" y="-225.8" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">gitVersion = "v0.5";</text>
|
||||
</g>
|
||||
<!-- dev_info -->
|
||||
<g id="node8" class="node"><title>dev_info</title>
|
||||
<text text-anchor="middle" x="309" y="-362.8" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">pkg/version/base.go:</text>
|
||||
<text text-anchor="middle" x="309" y="-347.8" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">gitVersion = "v0.5-dev";</text>
|
||||
</g>
|
||||
<!-- pr99 -->
|
||||
<g id="node9" class="node"><title>pr99</title>
|
||||
<polygon fill="#ccccff" stroke="black" points="143,-36 39,-36 39,-0 143,-0 143,-36"/>
|
||||
<text text-anchor="middle" x="91" y="-14.3" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">Merge PR #99</text>
|
||||
</g>
|
||||
<!-- pr99->ci012abc -->
|
||||
<g id="edge5" class="edge"><title>pr99->ci012abc</title>
|
||||
<path fill="none" stroke="black" d="M84.5805,-36.4245C81.5586,-44.6267 77.7879,-54.8615 73.9865,-65.1795"/>
|
||||
<polygon fill="black" stroke="black" points="70.6804,-64.0292 70.5075,-74.6226 77.2488,-66.4492 70.6804,-64.0292"/>
|
||||
</g>
|
||||
<!-- pr99->version_commit -->
|
||||
<g id="edge7" class="edge"><title>pr99->version_commit</title>
|
||||
<path fill="none" stroke="black" d="M97.4344,-36.0276C109.585,-68.1826 136.317,-138.924 154.498,-187.038"/>
|
||||
<polygon fill="black" stroke="black" points="151.318,-188.523 158.127,-196.64 157.866,-186.048 151.318,-188.523"/>
|
||||
</g>
|
||||
<!-- tag -->
|
||||
<g id="node11" class="node"><title>tag</title>
|
||||
<ellipse fill="#ffcccc" stroke="black" cx="226" cy="-115" rx="71.4873" ry="18"/>
|
||||
<text text-anchor="middle" x="226" y="-111.3" font-family="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" font-size="14.00">$ git tag -a v0.5</text>
|
||||
</g>
|
||||
<!-- tag->version_commit -->
|
||||
<g id="edge9" class="edge"><title>tag->version_commit</title>
|
||||
<path fill="none" stroke="black" d="M218.519,-132.939C212.168,-147.318 202.736,-168.673 194.103,-188.22"/>
|
||||
<polygon fill="black" stroke="black" points="190.784,-187.071 189.946,-197.632 197.188,-189.899 190.784,-187.071"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 7.1 KiB |
Loading…
Reference in New Issue