I am planning to run Jenkins in a Docker environment, as part of a more complex SDLC pipeline.

The expected benefits of running Jenkins in this environment is to have a canonical environment (immutable server pattern) and a “take-away” SDLC pipeline that can also be popped up locally if needed.

However, projects tested in Jenkins have dependencies which are not on the Jenkins base image. What is the common way to deal with it?

I see three possible approaches:

  • Craft an organization's specific Docker image with all the extra dependencies and repositories, evolve it as needed.

  • Let users defining jobs in Jenkins install distribution packages via sudo(1).

  • For each project, build a Docker image inside Jenkins, with all the required dependencies to build the project and use it to run the build and test chain.

To me the most natural approach would be third, as it also helps running integration tests via Jenkins. It requires a bit of engineering though. The sudo-version would be quite hard to implement without opening a huge security breach. What would be the best approach?

  • The best approach is wondering why you want to spin up a CI infrastructure for every project if you have nothing to bring a jenkins runner node with necessary dependencies in an automatic fashion without manual intervention – Tensibai Jun 21 '18 at 19:06
  • I.e: treat your ci infrastructure a cattle and be able to spin up a runner with needed dependencies, once done you can move to docker to package it with necessary knowledge on how to achieve it. – Tensibai Jun 21 '18 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.