Add kubernetes-e2e-gce job to git #18454
Conversation
|
Labelling this PR as size/L |
k8s-github-robot
added
the
size/L
|
GCE e2e build/test failed for commit 61b87d8f3538cca86cab1f9015d08b5e2b2b25bb. |
|
@ihmccreery #18116 |
| @@ -224,6 +224,7 @@ E2E_OPT=${E2E_OPT:-""} | |||
| # Set environment variables shared for all of the GCE Jenkins projects. | |||
| if [[ ${JOB_NAME} =~ ^kubernetes-.*-gce ]]; then | |||
| KUBERNETES_PROVIDER="gce" | |||
| : ${GCE_SERVICE_ACCOUNT:=$(cat /var/lib/jenkins/.gce/service_account)} | |||
There was a problem hiding this comment.
this file doesn't exist on all of our VMs. (In particular, none of the PR VMs have it.)
I wonder if using gcloud auth would be better?
There was a problem hiding this comment.
How would that work? It definitely sounds better than having to copy this file around.
There was a problem hiding this comment.
there's almost certainly a better way, but my 60s PoC (which works for now?):
gcloud auth list 2>/dev/null | grep active | cut -f3 -d' '
There was a problem hiding this comment.
I like that much more, thanks.
|
It's probably fine to no longer block on kubernetes-build failing, as long as we make it clear to everyone that tests continue with the latest successful build. |
|
GCE e2e test build/test passed for commit 4954508. |
+1 |
|
Is it a good idea to pull the environment variables out of e2e.sh and into the yaml file? It looks like we can only pull some of them out, the SKIP_TEST stuff is set at the top of e2e.sh. The rest we can move here. The EnvInject plugin is already installed on Jenkins and would make this quite easy. |
Let's wait on that. One thing at a time. 😄 |
|
Sounds good. Is there any reason not to make this replacement? Edit: The second one won't fail if the curl fails. Looks like a dead-end. curl -fsS -o upload-to-gcs.sh --retry 3 "..." && source upload-to-gcs.sh; rm -f upload-to-gcs.sh-> source <(curl -fsS --retry 3 "...") |
|
LGTM. I think I tried doing curl ... | source -before and it didn't work for some reason. Maybe your variation will... but let's maybe try changing one thing at a time? Which actually makes me wonder: how do we test changes to configs in this new system, given that latency is much higher than just tweaking something on the Jenkins UI? |
|
The To test changes to the configs I think it's reasonable to make a new jenkins job with "test-" before the name or something. If that's not going to work, I think it's reasonable to manually merge config changes in order to reduce the latency. The only thing that shouldn't happen is for someone to go into jenkins, make a config change, then forget about it. I'll sit there until someone touches that file in git, then it will be reverted. We could switch on ignore_cache in jenkins_jobs.ini to make it always update jobs, so that their change will be reverted next time the update job runs. |
|
Merging manually to watch Jenkins. |
Add kubernetes-e2e-gce job to git
I think it might be a good idea to add this job on its own, make sure it's working right, then add the rest of the GCE E2E tests in a second PR. For the most part they have the same settings, except for easy-to-substitute things like timeout duration or branch. I have backed up the current config.
Changes to the config:
Get Jenkins job configs under source control #18122