Change:
# we will run provision to update code each time we test, so we do not want to do salt install each time if ! which salt-minion >/dev/null 2>&1; then # Install Salt <del> # # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -X ## TODO this only works on systemd distros, need to find a work-around as removing -X above fails to start the services installed systemctl enable salt-minion systemctl start salt-minion </del> <ins> curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s </ins> fi # run the networking setup

Discussion:
Jenkins build Node/job/heapster-dockercanarybuild-ci/58/ failed since last Thursday due to compiling issue: looks like it is caused by
encountered this error when compiling heapster at local.
After updating the gce util library Heapster requires now go in version = 1.5. I'll fix the version in Jenkins config. ref , ,
The problem is with: heapster-dockercanarybuild-ci heapster-gce-e2e-ci could you please bump go version to 1.6 for those Jenkins jobs?
how are these builds getting the Go runtime? Just whatever's installed on the system?
/usr/local/go
Configured here:
Ah, okay, it is whatever is installed on the system. We should probably change this to use something version-controlled. (Ideally this would just be running inside Docker.) I can upgrade to go 1.6 in the interim. I think the only other use of the system Go runtime is in the e2e tests, which shouldn't care about the version of go.
Updated to go1.6 on post-commit Jenkins VMs. Haven't touched PR Jenkins (yet).
in case you see any breakages, see ^
Thanks for the heads up
this is still failing. And actually looking at the latest build log, I see why: You need to update
Thanks I'll fix it.
Well, that's for , at least. is using system Go, and it's failing due to changes in Go 1.6, I think.
Log from :
seems to work. This used to happen before.
Suite heapster-gce-e2e-ci is still failing, this time with the message:
sorry, I missed that you pasted the same failure. I'll take w look.
has not passed in over a month. I'm going to send out a PR to disable it
As I wrote in the job has passed only once during its first run and then it failed 1000+ times. Was it supposed to work anytime?
If the solution is to delete this job that is totally fine by me
Decreasing priority since the job is disabled. do you know who set up the job?
do you know who created the suite? What should it test? The suite passed only 1/1175 runs.

had setup these jobs originally as part of migrating over to k8s jenkins server from my own jenkins server. The PR builder and HEAD CI should both be sharing the same framework ideally.
Thanks for the explanation. What is HEAD CI? I'll try to resurrect the suite. did you finish all the required work on this? Especially the suite passed only once and then failed 1000+ times.
I believe the suite was passing before the failures you see, but when it was converted to use jenkins-job-builder, the job was renamed and the count reset. It is possible the failures are related to something with the jjb change. After the initial migration from vish's jenkins server, I remember that they were passing for a while.
CI head is the "heapster-gce-e2e-ci" job running on the jenkins continuous integration server (as opposed to the jenkins PR builder server)
Thanks for clarification.
Let me know if it would be helpful to do a knowledge transfer about how the jenkins jobs are setup.
Removing flake label as this is not a flake.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig instrumentation because heapster /assign closing due to inactivity
/close