title: How to dynamically pick a git branch to use in Jenkins build
body: <p>I'm trying to create a new project configuration for Jenkins build server. To simplify what I'm trying to do, I will use only two components to describe the problem.</p>
  
  <p>ComponentA</p>
  
  <ul>
  <li>Change in this component triggers the build of this project on CI server. </li>
  <li>CI server has statically configured branch to monitor for changes and build. Eg. master or develop branch.</li>
  <li>This component contains a configuration file with required version of ComponentB it depends on. </li>
  </ul>
  
  <p>ComponentB</p>
  
  <ul>
  <li>Changes to this component don't trigger build of this project on CI server (there will be another project to cover development of ComponentB).</li>
  <li>Individual versions of component are tagged</li>
  <li>ComponentA has required version of ComponentB in its configuration file</li>
  <li>CI server does not know what branch (tag) to checkout until configuration file of ComponentA is somehow parsed.</li>
  </ul>
  
  <p>What is the right way to achieve this on Jenkins? I was trying to find out how to add this dynamic behavior of parsing the config file and making Git Plugin to check out branch based on expected version of ComponentB but so far I have no clue.</p>
  
  <p>In the next step I may even want to have wildcards (like 5.3.*) in configuration file so I will have to find a the newest ComponentB's tag matching the wildcard.</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>Now I see that I simplified my problem too much and due to the simplification, the main limitation is no longer present.</p>
  
  <p>The main limitation is that Component A and B must be built together. It is not possible to build them separately as they form one executable / library and the build script needs source files from both components.</p>
  
  <p>If you ask why such a strange configuration, let's give Component A and B some description:</p>
  
  <ul>
  <li>ComponentA: Native platform specific code</li>
  <li>ComponentB: Native platform independent code</li>
  </ul>
  
  <p>There may be many Component As - one for each platform, but just single Component B. Merging particular A with B produces full source code for single platform but not every platform may be updated to the latest version of B so it needs to have control over which version of B should be used for built.</p>