Migrate CI job definitions into the .ci directory.

[michaelbaamonde]

This commit migrates our Jenkins job definitions into the Rally repository. It also adds a view called "Rally" to the CI cluster's landing page that includes the jobs defined here.

I tested each of these jobs--except for the docker-release job--with a local Jenkins master that is configured identically to the one controlling https://elasticsearch-ci.elastic.co. It spun up ephemeral workers in GCP to run the builds, which were also configured identically to those that a production build would run on.

Regarding docker-release, I didn't want to assume that running the job with an already-released version of Rally would be a true no-op. The actual contents of the job are identical to what we've been using, but if folks would like to test it out somehow anyway, I'm happy to figure out how to do that safely.

[dliappis]

This is very very helpful!

Left a few comments. We can sync offline too.

[dliappis]

I think in a future PR we could remove it from here, and move it to the shell script below with something like

#!/usr/bin/env bash

JAVA_ROOT=/var/lib/jenkins/.java

export JAVA7_HOME=${JAVA_ROOT}/java7
export JAVA8_HOME=${JAVA_ROOT}/java8
export JAVA9_HOME=${JAVA_ROOT}/java9
export JAVA10_HOME=${JAVA_ROOT}/java10
export JAVA11_HOME=${JAVA_ROOT}/java11

# handle all Javas after that generically
for java in ${JAVA_ROOT}/openjdk??
do
  version=${java##*openjdk}
  export JAVA${version}_HOME=$java
done

Or we could leverage the latest truth of the latest elasticsearch master branch here: https://github.com/elastic/elasticsearch/blob/master/.ci/java-versions.properties and construct the necessary JAVAX_HOME variables.

Also I think we could remove ES_JAVA_HOME. As I mentioned this is an improvement so could like in a future PR.

[michaelbaamonde]

Sure, I like this idea!

[dliappis]

should this match the name of the Jenkins cluster? e.g. elasticsearch-ci? (it's possible it doesn't matter, would be nice to know what this is about).

[michaelbaamonde]

It's just the name of the PR check. If you take a look at this PR's checks, for example, you'll see one called "tests".

[dliappis]

I think we need to test / look a bit deeper here.

For ref check these internal links:

link 1
link 2
link 3

and

link 4

[michaelbaamonde]

As discussed offline, I'll look into how to test that we're good here.

[dliappis]

We've faced this issue elsewhere, we need to prefix with set -o errexit because it's possible that tests failed via build.sh but then CI reports success due to the archive function below returning true.

[michaelbaamonde]

I'm going to close this one out. After talking with @dliappis, we have some new, better patterns that we're using elsewhere. When I'm able to focus on this work again, I'll re-issue using the latest and greatest.