We have a good document on investigating flaky tests, but it can
be hard to correlate personal experience (my PR wont pass presubmits!?!)
with broader CI health (did AWS go down?). For that portion of
triage it's useful to look at some aggregated statistics and we have
two nice pages for that.
I'm always forgetting these two links though and while some kind
folks have reminded me repeatedly, I take that as a sign it's time
to put them somewhere more visible.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
The sig-release repo has a set of old documentation looking for a
better home. The issues.md document there describes how a developer
targets an issue (or PR) to a milestone release. This logically
fits better in the community/contributors/devel/ guide, so this commit
brings it in and a parallel commit will remove it from the other repo.
With it comes two pictures of what a release cycle and the overall
release lifecycle look like.
The issues.md content is modified a bit to add more information
about the release process overall and remove outdated information
around the bot-driven workflow for targeting work to a milestone, and is
named release.md here.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
As detect-master method[1] of the provider "local", the variables
of KUBE_MASTER and KUBE_MASTER_IP are hardcoded. Then it is not
necessary to specify them on user side. In addition, the original
description shows KUBE_MASTER=local, but that is completely wrong
that should be localhost as the code[1].
This patch removes this unnecessary discription.
[1]: 2bdae8f3d0/cluster/local/util.sh (L21)
The `hack/run-in-gopath.sh hack/godep-restore.sh` command shows no progress information and it can take a lot of time, so it's good to mention that if you want to see what is happening, you can use the `-v` flag to turn on verbose mode of `godep restore`.
Searches for how to backport PRs to release branches are difficult if
you don't know what you're looking for. Add a sentence with that word to
make searching easier.
A recent commit in the sig-release repo moved some documentes. These
tombstoned redircts in the community repo haven't yet expired so should
conntinue to work and need updated links.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
On the release team I've seen a number of issues go by this year
where vendor code was updated and later implicated in issue triage
and bisection, but the original commits didn't sufficiently document
the change. Reverting the update then reintroduced a previously
fixed issue, which was insufficiently documented in the changelog. The
subsequent churn led to a lot of work by multiple people to resolve.
Terse godep vendor code update commit messages seem to be the norm and
we should aim higher.
Signed-off-by: Tim Pepper <tpepper@vmware.com>
Some examples have proto tags and some don't. Since proto tags are
generated and not manually written, this commit removes the proto tags
from the examples to remain consistent.
k8s-ci-robot