Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

@k8s-bot ok to test

thanks! one minor request.

Also, you need to run:

hack/update-munge-docs.sh

I did run update-mungedocs before commit and the commit checks did pass (the commit checks don't pass till you run it). When I run it I get the following output:

mike@mike-VirtualBox:~/go/src/k8s.io/kubernetes$ sudo hack/update-munge-docs.sh
[sudo] password for mike:
make: Entering directory '/home/mike/go/src/k8s.io/kubernetes'
make[1]: Entering directory '/home/mike/go/src/k8s.io/kubernetes'
I0804 09:51:24.789659 755 main.go:73] Completed successfully.
make[1]: Leaving directory '/home/mike/go/src/k8s.io/kubernetes'
Go version: go version go1.6.2 linux/amd64
+++ [0804 09:51:25] Generating bindata:
/home/mike/go/src/k8s.io/kubernetes/test/e2e/framework/gobindata_util.go
KUBE_ROOT not detected, setting default.
Generated bindata file : 11561 ../../..//test/e2e/generated/bindata.go lines of lovely automated artifacts
+++ [0804 09:51:27] Building the toolchain targets:
k8s.io/kubernetes/hack/cmd/teststale
+++ [0804 09:51:27] Building go targets for linux/amd64:
cmd/mungedocs
+++ [0804 09:51:27] Placing binaries
make: Leaving directory '/home/mike/go/src/k8s.io/kubernetes'
output: fatal: Not a valid object name upstream/release-1.3
,
ERROR: exit status 128
git ls-tree -r --name-only upstream/release-1.3 failed. We'll ignore this error locally, but Jenkins may pick an error. Munger uses the output of this command to determine in unversioned warning, if it should add a link to the doc in release branch. output: fatal: Not a valid object name upstream/release-1.3 , ERROR: exit status 128 git ls-tree -r --name-only upstream/release-1.3 failed. We'll ignore this error locally, but Jenkins may pick an error. Munger uses the output of this command to determine in unversioned warning, if it should add a link to the doc in release branch.
output: fatal: Not a valid object name upstream/release-1.3
,
ERROR: exit status 128
`git ls-tree -r --name-only upstream/release-1.3 failed. We'll ignore this error locally, but Jenkins may pick an error. Munger uses the output of this command to determine in unversioned warning, if it should add a link to the doc in release branch.

Thoughts?

Here's my git config ... am I missing an additional remote upstream?

remote.origin.url=https://github.com/mikebrow/kubernetes.git
remote.origin.fetch=+refs/heads/:refs/remotes/origin/
branch.master.remote=origin
branch.master.merge=refs/heads/master
remote.upstream.url=https://github.com/kubernetes/kubernetes.git
remote.upstream.fetch=+refs/heads/:refs/remotes/upstream/
branch.devel-tree-80col-updates-B.remote=origin
branch.devel-tree-80col-updates-B.merge=refs/heads/devel-tree-80col-updates-B

The command git ls-tree -r --name-only HEAD works but not git ls-tree -r --name-only upstream/release-1.3 as that is not a valid object name.

rebased

@david-mcmahon any ideas about the munge-docs error above?

I'm not sure it is correct for a script to assume there is a git remote named upstream. Is that documented somewhere?

update-munge-docs was written with a dependency on a remote named upstream. I work around it myself with the release tooling. It may be 'fixable', but I never looked close enough. I suspect most people use the standard dev env and never encounter this.

Ok.. talked it over with @MHBauer I was using fetch on upstream master not upstream so I was not getting the extra tags or something.

rebased and re-ran hack/update-munge-docs.sh should be good to go now

I like the choice to get the godep details out of the fast path.

@ixdy
You must link to the test flake issue which caused you to request this manual re-test.
Re-test requests should be in the form of: k8s-bot test this issue: #<number>
Here is the list of open test flakes.

LGTM

@k8s-bot e2e test this issue: #30454

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

@k8s-bot ok to test
@k8s-bot unit test please issue: IGNORE

(looks like a general CI failure)

GCE e2e build/test passed for commit 497c211.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue