We eventually want the releases-jenkins instance to run tests and integrate security patches and automagically cut releases.
Since these tests have a large overlap with our existing CI jenkins we could use the existing integration/config JJB to store job definitions. Alternatively, we could use a new repository using either JJB or the Jenkins Pipeline (either declarative or groovy variants).
Using integration/config
Pros
- Lots of edge-cases handled already, tests are vetted ever day due to heavy use
- As tests change in ci-jenkins, there will not be any additional work needed to update releases-jenkins tests (although divergence of needs is a con)
- Less setup work needed (possibly) since there are already existing tests
- Familiarity: everyone involved with the releases-jenkins project has some level of familiarity with integration/config
Cons
- Lots of likely unneeded configuration for jobs
- I don't anticipate releases-jenkins using zuul, so many of the job definitions will be incompatible
- The way we deploy jobs via jenkins-job-builder will need to be scripted to only deploy a subset of jobs/current documentation for jjb deployment will need to be updated
- The needs of releases-jenkins may significantly diverge from the needs of ci-jenkins resulting in the need to split repositories eventually