Answers: <p>I have sometimes used the pattern where all pipeline things go in a <code>.pipeline/</code> directory of the app, including the Jenkinsfile. I would, in your case, add several pipelines (ie, Jenkinsfiles) - one per microservice as you propose, and one for the web app.</p>
  
  <p>Then, you define independent multibranch pipeline jobs, based on the location of the pipelines. In other words, you create 5 multibranch pipeline jobs, (one for the web app, one for each microservice), and attach each job to the relevant pipeline file in your repsitory. In this way, they will be tested independently.</p>
  
  <p>The important thing is to properly specify the correct triggers. The microservices will be triggered on changes to code in their path. They may also have as post-build actions the triggering of the web app pipeline, for integration tests, <em>etc</em>.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-07-05T08:24:52.987Z
Answers: 2019-07-05T08:24:52.987Z
Answers: Bruce Becker
Body: <p>I'm currently working on a Microservice architecture-based project and writing Jenkins Pipeline for it.</p>
  
  <p>The project structure is as follows:</p>
  
  <p>Web Service (master)</p>
  
  <ul>
  <li>Jenkinsfile</li>
  <li>Service 1/
  
  <ul>
  <li>Jenkinsfile</li>
  </ul></li>
  <li>Service 2/
  
  <ul>
  <li>Jenkinsfile</li>
  </ul></li>
  <li>Service 3/
  
  <ul>
  <li>Jenkinsfile</li>
  </ul></li>
  </ul>
  
  <p>Within each Service, there will be a Jenkinsfile that contains information on building and testing for the specific service.</p>
  
  <p><strong>How do I use the Jenkinsfile on the base directory to build and test each individual Services before running integration test on a cross service level ?</strong></p>
  
  <p>I've been trying to look for ways to implement this, but the build seems to target project level, it is said to be able to process relative file path but I haven't had much success with it.</p>
  
  <p>I have tried loading, but load seems to be made for groovy file, which doesn't seem to fit the requirement.</p>
  
Tags: <jenkins><jenkins-pipeline><jenkins-plugins><jenkinsfile>
Title: Jenkinsfile for monorepo & monobranch
UserDisplayName: puayhiang
ThreadText: # Jenkinsfile for monorepo & monobranch
  
  (Asked by: username_0 on 2019-07-05)
  
  I'm currently working on a Microservice architecture-based project and writing Jenkins Pipeline for it.
  
  The project structure is as follows:
  
  Web Service (master)
  
  * Jenkinsfile
  * Service 1/
    + Jenkinsfile
  * Service 2/
    + Jenkinsfile
  * Service 3/
    + Jenkinsfile
  
  Within each Service, there will be a Jenkinsfile that contains information on building and testing for the specific service.
  
  **How do I use the Jenkinsfile on the base directory to build and test each individual Services before running integration test on a cross service level ?**
  
  I've been trying to look for ways to implement this, but the build seems to target project level, it is said to be able to process relative file path but I haven't had much success with it.
  
  I have tried loading, but load seems to be made for groovy file, which doesn't seem to fit the requirement.
  
  **Tags:** jenkins, jenkins-pipeline, jenkins-plugins, jenkinsfile
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-07-05. Score: 0 | Accepted answer
  
  I have sometimes used the pattern where all pipeline things go in a `.pipeline/` directory of the app, including the Jenkinsfile. I would, in your case, add several pipelines (ie, Jenkinsfiles) - one per microservice as you propose, and one for the web app.
  
  Then, you define independent multibranch pipeline jobs, based on the location of the pipelines. In other words, you create 5 multibranch pipeline jobs, (one for the web app, one for each microservice), and attach each job to the relevant pipeline file in your repsitory. In this way, they will be tested independently.
  
  The important thing is to properly specify the correct triggers. The microservices will be triggered on changes to code in their path. They may also have as post-build actions the triggering of the web app pipeline, for integration tests, *etc*.
  
  
  ---
  
  