Answers: <p>You can use a <a href="https://jenkins.io/doc/book/pipeline/jenkinsfile/" rel="nofollow noreferrer">Jenkinsfile</a> for this. You can add logic  with <a href="http://groovy-lang.org/" rel="nofollow noreferrer">groovy</a> for every condition you've listed above.</p>
  
  <p>You'll want to use a multi-branch pipeline build for sure, and just write in conditions / switches to determine what you want to do based on the current branch. Jenkins provides a global environment variable for all builds: <strong>BRANCH_NAME</strong></p>
  
  <p>The job will run on any branch that contains the Jenkinsfile and you can write conditions in for steps if you  want to include / exclude certain branches. You can use the <strong>when</strong> directive for full-step conditions: <a href="https://jenkins.io/doc/book/pipeline/syntax/#when" rel="nofollow noreferrer">https://jenkins.io/doc/book/pipeline/syntax/#when</a></p>
  
  <p>For handling credentials: <a href="https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials" rel="nofollow noreferrer">https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials</a></p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-26T05:06:19.703Z
Answers: 2018-01-26T05:06:19.703Z
Answers: caylorme
Answers: <p>My two cents with respect to AWS part:</p>
  
  <ul>
  <li><p>If you have to use different VPCs, and accounts in AWS, I suggest you should have a look at <strong>AWS IAM</strong> roles and assign appropriate policies to the roles; also, ensure these roles are associated with <strong>AWS EC2</strong> instance profiles that can be attached to EC2 instances, if they are used as build agents. That way you won't have to store AWS credentials but go with <strong>AWS STS</strong>.</p></li>
  <li><p>As you have mentioned about <strong>AWS ECR</strong>, let me tell you about Docker Plugin installed -- with these plugins, Jenkinsfile can become very crisp to write and maintain using the steps exposed by the plugin, including the tasks to build the image, tag the image and push the image to the registry.</p></li>
  <li><p>Better yet, you can have metadata YAML for every service / component that can specify details about AWS ECR and write Groovy scripts to detect the change to YAML, only then build new version of the Docker image.</p></li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-05-28T02:37:22.667Z
Answers: 2018-05-28T02:37:22.667Z
Answers: Ramu
Body: <p>Here are my requirements and I go back-and-forth on how to achieve them:</p>
  
  <ul>
  <li>Must build Java spring-boot apps</li>
  <li>Artifacts must be released to artifactory repository</li>
  <li>Docker image to be built directly relating to the artifact <code>group/artifactId/version</code></li>
  <li>Docker image to be deployed to AWS ACR</li>
  <li>Container deployment via cloud formation</li>
  <li>Maintain 2 branches in a git repo: <code>dev</code> and <code>master</code>. <code>dev</code> releases to our development environment and <code>master</code> is for prod (I have tried to explain that this approach made sense when code was app (php) but not when you have a release artifact)</li>
  <li>All branches off <code>dev</code> must build and test independently but NOT release even snapshots (doesn't apply to master as no one should be working off master)</li>
  <li><strong>best part</strong> <code>dev</code> and <code>prod</code> builds must be done under entirely different AWS credentials and accounts into totally different VPCs</li>
  </ul>
  
  <p>Given these requirements I believe need a <code>multi-configuration</code> pipeline - one for the {prod/master} and {development/dev} arrangement to successfully capture the credential and deployment differences and point them at different branches. What I can't seem to do is get the <code>dev</code> configuration to ALSO build the branches from dev - I have no pattern I can match - the branches don't look like <code>dev-.*</code> - they are mapped directly to Jira tickets.</p>
  
  <p>Can I even do such a thing? I feel like this last part is where my multi-config is breaking down.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-10-11T13:58:44.880Z
Comments: What about using negative matching? That is, use a "NOT master" pattern.
Comments: B Layer
Comments: CC BY-SA 4.0
Comments: 2021-04-15T19:27:28.463Z
Comments: Just wondering if you ever managed to figure out a solution to this? I am in the exact same scenario where my apps have to go to Nexus (as opposed to Artifactory ... but that doesn't really matter when using Maven), and a deployment pipeline must deploy to different environments with different deployment configurations (with/without high availability / different worker sizes (t2.micro, t2.nano, t2.medium, etc) depending on the environment being deployed to).
Comments: justin.saliba
Tags: <jenkins><docker><amazon-web-services><git><spring-boot>
Title: Jenkins configuration to support multi-config multi-branch CI
UserDisplayName: Christian Bongiorno
ThreadText: # Jenkins configuration to support multi-config multi-branch CI
  
  (Asked by: username_0 on 2017-07-11)
  
  Here are my requirements and I go back-and-forth on how to achieve them:
  
  * Must build Java spring-boot apps
  * Artifacts must be released to artifactory repository
  * Docker image to be built directly relating to the artifact `group/artifactId/version`
  * Docker image to be deployed to AWS ACR
  * Container deployment via cloud formation
  * Maintain 2 branches in a git repo: `dev` and `master`. `dev` releases to our development environment and `master` is for prod (I have tried to explain that this approach made sense when code was app (php) but not when you have a release artifact)
  * All branches off `dev` must build and test independently but NOT release even snapshots (doesn't apply to master as no one should be working off master)
  * **best part** `dev` and `prod` builds must be done under entirely different AWS credentials and accounts into totally different VPCs
  
  Given these requirements I believe need a `multi-configuration` pipeline - one for the {prod/master} and {development/dev} arrangement to successfully capture the credential and deployment differences and point them at different branches. What I can't seem to do is get the `dev` configuration to ALSO build the branches from dev - I have no pattern I can match - the branches don't look like `dev-.*` - they are mapped directly to Jira tickets.
  
  Can I even do such a thing? I feel like this last part is where my multi-config is breaking down.
  
  **Tags:** jenkins, docker, amazon-web-services, git, spring-boot
  
  > **Comments:**
  > **username_1**: What about using negative matching? That is, use a "NOT master" pattern.  
  > **username_2**: Just wondering if you ever managed to figure out a solution to this? I am in the exact same scenario where my apps have to go to Nexus (as opposed to Artifactory ... but that doesn't really matter when using Maven), and a deployment pipeline must deploy to different environments with different deployment configurations (with/without high availability / different worker sizes (t2.micro, t2.nano, t2.medium, etc) depending on the environment being deployed to).  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2018-01-26. Score: 2
  
  You can use a [Jenkinsfile](https://jenkins.io/doc/book/pipeline/jenkinsfile/) for this. You can add logic with [groovy](http://groovy-lang.org/) for every condition you've listed above.
  
  You'll want to use a multi-branch pipeline build for sure, and just write in conditions / switches to determine what you want to do based on the current branch. Jenkins provides a global environment variable for all builds: **BRANCH\_NAME**
  
  The job will run on any branch that contains the Jenkinsfile and you can write conditions in for steps if you want to include / exclude certain branches. You can use the **when** directive for full-step conditions: <https://jenkins.io/doc/book/pipeline/syntax/#when>
  
  For handling credentials: <https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials>
  
  
  ---
  
  ### Answer by username_4 on 2018-05-28. Score: 0
  
  My two cents with respect to AWS part:
  
  * If you have to use different VPCs, and accounts in AWS, I suggest you should have a look at **AWS IAM** roles and assign appropriate policies to the roles; also, ensure these roles are associated with **AWS EC2** instance profiles that can be attached to EC2 instances, if they are used as build agents. That way you won't have to store AWS credentials but go with **AWS STS**.
  * As you have mentioned about **AWS ECR**, let me tell you about Docker Plugin installed -- with these plugins, Jenkinsfile can become very crisp to write and maintain using the steps exposed by the plugin, including the tasks to build the image, tag the image and push the image to the registry.
  * Better yet, you can have metadata YAML for every service / component that can specify details about AWS ECR and write Groovy scripts to detect the change to YAML, only then build new version of the Docker image.
  
  
  ---
  
  