Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use CI .deb builds in kubeadm e2e job. #2180

Merged
merged 1 commit into from
Mar 9, 2017
Merged

Use CI .deb builds in kubeadm e2e job. #2180

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions jobs/ci-kubernetes-e2e-kubeadm-gce.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,9 +26,18 @@ readonly testinfra="$(dirname "${0}")/.."

export PROJECT="k8s-jkns-e2e-kubeadm-gce-ci"
export KUBERNETES_PROVIDER=kubernetes-anywhere

# This job only runs against the kubernetes repo, and bootstrap.py leaves the
# current working directory at the repository root. Grab the SCM_REVISION so we
# can use the .debs built during the bazel-build job that should have already
# succeeded.
export SCM_VERSION=$(./hack/print-workspace-status.sh | grep ^STABLE_BUILD_SCM_REVISION | cut -d' ' -f2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks very magical, given here we are going to only support env vars, could this logic be in the kubeadm image?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm, I don't think it can be in the image runner. The call stack looks like:

ci-kubernetes-e2e-kubeadm/runner # image entrypoint
\-> bootstrap.py
   \-> jobs/ci-kubernetes-e2e-kubeadm-gce.sh (the script in question)
      \-> e2e-runner.sh
         \-> kubetest

The kubernetes repo gets pulled by bootstrap.py, so the logic needs to be executed after that step, and I need to adjust the E2E_OPTS before e2e-runner.sh is invoked. I thought the job script was the perfect place for this, but if we only want to support static environment variables there, then does that mean I'll need to create a custom scenario to support this kind of logic (like kops has)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can get this in to make the test green first, and we can figure out where to move the logic to. It's easy to add a flag to the e2e scenario.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, what? bootstrap.py should be launching an image, the runner should not be calling bootstrap.py

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fejta That may be the case when the job runs under Jenkins and uses dockerized-e2e-runner.sh, but this is a prow job, so it has its own custom Docker image. Prow launches the image defined in config.yaml, and the rest of the chain is the above, with the job calling e2e-runner.sh instead of dockerized-e2e-runner.sh to avoid Docker-in-Docker.

@krzyzacy Sounds good to me. Did you have any other feedback about the diff, or was that a very informal LGTM? :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies! I clearly don't have the right context here. I'll get out of your way

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fejta this is within prow, so it's more like local mode, but it's not using e2e scenario yet.

I'll let @fejta have the final stamp, see if he agrees with me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems he decided to throw this to me 👿

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fejta No worries, thanks for trying to help out. And yeah, this is definitely to support local testing of the job, but shouldn't actually affect how it runs in prow.

@krzyzacy Thanks. :-)


export E2E_NAME="e2e-kubeadm-gce"
export E2E_OPT="--deployment kubernetes-anywhere --kubernetes-anywhere-path /workspace/kubernetes-anywhere"
export E2E_OPT+=" --kubernetes-anywhere-phase2-provider kubeadm --kubernetes-anywhere-cluster ${E2E_NAME}"
# The gs:// path given here should match jobs/ci-kubernetes-bazel-build.sh
export E2E_OPT+=" --kubernetes-anywhere-kubeadm-version gs://kubernetes-release-dev/bazel/${SCM_VERSION}/build/debs/"
export GINKGO_TEST_ARGS="--ginkgo.focus=\[Conformance\]"

### post-env
Expand Down