<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Roopak Venkatakrishnan</title>
    <description>The latest articles on DEV Community by Roopak Venkatakrishnan (@roopakv).</description>
    <link>https://dev.to/roopakv</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F361882%2F6285a62a-034f-4d21-8873-72f5d107b0c8.jpg</url>
      <title>DEV Community: Roopak Venkatakrishnan</title>
      <link>https://dev.to/roopakv</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/roopakv"/>
    <language>en</language>
    <item>
      <title>Breaking up the CircleCI yaml into multiple files</title>
      <dc:creator>Roopak Venkatakrishnan</dc:creator>
      <pubDate>Mon, 13 Apr 2020 15:55:10 +0000</pubDate>
      <link>https://dev.to/roopakv/breaking-up-the-circleci-yaml-into-multiple-files-78e</link>
      <guid>https://dev.to/roopakv/breaking-up-the-circleci-yaml-into-multiple-files-78e</guid>
      <description>&lt;p&gt;As an org if you use CircleCI, over time you will notice that config file really increase in length. One of the repos I worked on hit ~3000 lines. It starts becoming unwieldy, reviewing changes is hard and making changes is harder still. Sadly CircleCI doesn't support reading from multiple files. But do not fret, this blog post will show you how you can do this.&lt;/p&gt;

&lt;p&gt;Turns out Circle built most of what is required, into their CLI. Read about it here. Start out by breaking your config into multiple files as described in the circle article. You can see how I broke up my yml in &lt;a href="https://github.com/roopakv/circle-yml-split-example"&gt;this repo&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Through the rest of this post we refer to the smaller yml file as sub-ymls and the main config.yml as the config.&lt;/p&gt;

&lt;p&gt;The &lt;code&gt;.circleci/src&lt;/code&gt; directory contains the files that combine to to form &lt;code&gt;.circleci/config.yml&lt;/code&gt;. We have a make command &lt;code&gt;make circle-config&lt;/code&gt; which combines the sub-ymls to the main config&lt;/p&gt;

&lt;p&gt;The interesting part which isn't covered by CircleCI is how you force a build to break if someone modifies one of the sub-ymls and forgets to compile the main config. Notice in the &lt;a href="https://github.com/roopakv/circle-yml-split-example/blob/master/.circleci/src/jobs/lint-and-test.yml#L6"&gt;lint and test file&lt;/a&gt;, we have a command that fails the build if CircleCI config was not generated.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;- swissknife/build_and_check_circle_config:
    custom-error-message: Please run "make circle-config" and push up.
    fail-if-dirty: true
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;An example &lt;a href="https://github.com/roopakv/circle-yml-split-example/pull/1"&gt;pull request&lt;/a&gt; shows how the build is failed if only the sub ymls and not the main config.yml is modified. This prevents divergence of code.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--gMs9W1p7--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/9bed09tlzuakhgvku7cl.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--gMs9W1p7--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/9bed09tlzuakhgvku7cl.png" alt="Example Circle build showing fail if only sub yamls are modified"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://circleci.com/orbs/registry/orb/roopakv/swissknife"&gt;Swissknife&lt;/a&gt; is an orb, that has multiple useful commands and the &lt;code&gt;build_and_check_circle_config&lt;/code&gt; commands fails the build if git is dirty after the circle config was generated.&lt;/p&gt;

&lt;p&gt;In this example Swissknife checks if git is dirty after generating circle config. This means if anyone modified config directly or they modify the sub-ymls and not generate the config, the build will fail. The command can also be set up to push the difference in config to the origin.&lt;/p&gt;

</description>
      <category>circleci</category>
      <category>swissknife</category>
      <category>buildpipelines</category>
      <category>orbs</category>
    </item>
  </channel>
</rss>
