CI with Multiple Targets in 1 project

<p>I have a project that will have multiple executable targets. We did this so that we can re-use common code but using Jenkins it seems that we will need to re-create all the executables each time there is a commit to the &#39;master&#39; branch. This seems pretty wasteful plus it might cause a lot of churn for QA which now has to re-test all those new executables? How are other people using CI in a multiple target project?</p> <p>Thanks for any help!!</p> <p>Paul</p> <hr/>**评论：**<br/><br/>cdarw1n: <pre><p>Fatih recently gave a talk about how Digital Ocean manages a monorepo of mostly Go packages. He mentions that they wrote a tool in house to solve this, however I don’t believe they have released it as open source (yet). The general idea is for your build/test tool to run against only packages which have been modified in the current change set. The only real trick is to recursively check any of your own internal or “common” packages that your modified packages import.</p> <p><a href="https://speakerdeck.com/farslan/go-at-digitalocean" rel="nofollow">https://speakerdeck.com/farslan/go-at-digitalocean</a></p></pre>jerf: <pre><p>I&#39;m not sure if this is 100% true, but a brief stab at the command line says Go building is deterministic. Therefore, it should suffice only to test executables whose hashes have changed.</p> <p>It is still possible for executables to change even if they haven&#39;t been &#34;changed&#34;, because Go IIRC does no dead code removal, so if you have a module that adds a constant that some executable ends up not using, it will still change the hash of the new executable. At this point, though, you start getting into some pretty philosophical questions about what exactly is worth QA&#39;ing.</p> <p>If certain pieces of certain modules are changing a lot, but only some executables need them, you could break them up.</p></pre>carsncode: <pre><p>The Go compiler does dead code removal.</p></pre>BadlyCamouflagedKiwi: <pre><p>Go has a linker, so functions that are trivially not used will normally not appear in the final executable and thus it won&#39;t change if they do.</p> <p>Dead code within functions is more subtle; change in line numbers and so forth may still alter the final executable even if the actual instructions haven&#39;t. That sort of thing is unlikely to be your biggest concern in CI though (if it is, you&#39;re doing pretty well...).</p></pre>Frakturfreund: <pre><p>Have you tried how go tip/master/trunk performs for you?</p> <p>Because the <a href="https://tip.golang.org/doc/go1.10#build" rel="nofollow">new cache in Go 1.10</a> may speed up your use case.</p></pre>Redundancy_: <pre><p>This isn&#39;t so much Go, as general software engineering, I think.</p> <p>If you have a repository where anything can change, and any change could affect any of your potential builds and tools in that repository... then you&#39;re in a situation where any change could break anything, and need to respond accordingly. If you don&#39;t have automated tests you can trust to cover things it can be very painful.</p> <p>This is a push model, where anyone can submit a change that&#39;s effectively &#34;pushed&#34; to all projects instantly. It means that everything can be updated &#34;atomically&#34; (assuming simultaneous deployment), but it also means that you&#39;re fragile to breakage from people outside of your team. </p> <p>You might be able to do a bit better with <a href="https://dave.cheney.net/2014/09/14/go-list-your-swiss-army-knife" rel="nofollow">https://dave.cheney.net/2014/09/14/go-list-your-swiss-army-knife</a> by listing dependencies for each executable and comparing against the change-set.</p> <p>A &#34;pull&#34; model is where each tool is isolated, and only decides to get changes when they&#39;re valuable. You control and pin your dependencies to avoid unexpected change and breakage, but you can&#39;t assume that a change to a library will propagate, and have to isolate assumptions and version to control for that. It&#39;s also more work, because you have to coordinate and convince teams to pull updates.</p> <p>I&#39;ve worked in a large version of a mono-repository with multiple teams and some shared &#34;util&#34; libraries that made this a nightmare. Things breaking left right and center because people picked up functionality they found and used it, others who didn&#39;t know who was using it changed stuff. If you want safety, and don&#39;t have great automated test coverage, I&#39;d really suggest managing your dependencies. If you have something where every tool always needs to be updated simultaneously because of changes to it, it can be a real red-flag.</p></pre>