<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>john-tells-all</author><text>&amp;gt; - Put all build&amp;#x2F;publish&amp;#x2F;test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well.&lt;p&gt;This is critical!&lt;p&gt;In many teams Devs are &amp;quot;lazy&amp;quot;, if any errors or weirdness happens in CI they just wave their hands and say &amp;quot;not a feature, not my problem&amp;quot;. Even though they know exactly what&amp;#x27;s in the test code, the deploy code, and can see the issue.&lt;p&gt;Letting Devs see and run the CI scripts locally gives them _ownership_. They don&amp;#x27;t have to fix the issues, but they have control and understanding which radically reduces the arguments and pipeline drama :)</text><parent_chain><item><author>zdw</author><text>All of the test runners have their issues.  I&amp;#x27;ve had as much problems with Jenkins as I&amp;#x27;ve had with Github Runners and similar solutions.&lt;p&gt;The best way out of this is to subdivide responsibilities:&lt;p&gt;- Put all build&amp;#x2F;publish&amp;#x2F;test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well.  The only interaction between a test runner and the codebase should be running `make &amp;lt;target&amp;gt;`.&lt;p&gt;- Put all permissions and code checkout and artifact publishing credentials in the test runner, but no logic. At most you would put processing of test output like making junit&amp;#x2F;coverage&amp;#x2F;tap more web-readable.&lt;p&gt;That&amp;#x27;s it. Split the efforts cleanly, and things fall into place.  Also, you can switch runners easily - less needs to be reimplemented in whatever runner config DSL is picked.</text></item></parent_chain></comment><story><title>The worst thing about Jenkins is that it works (2019)</title><url>http://twitchard.github.io/posts/2019-06-21-life-is-too-short-for-jenkins.html</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>sevagh</author><text>&amp;gt;- Put all build&amp;#x2F;publish&amp;#x2F;test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well. The only interaction between a test runner and the codebase should be running `make &amp;lt;target&amp;gt;`.&lt;p&gt;This always breaks because then each platform has a specific way of defining env vars or secrets for those Makefiles and bash scripts. End result is devs still can&amp;#x27;t really run CI &amp;quot;proper&amp;quot; the way it&amp;#x27;s configured in a runner.</text><parent_chain><item><author>zdw</author><text>All of the test runners have their issues.  I&amp;#x27;ve had as much problems with Jenkins as I&amp;#x27;ve had with Github Runners and similar solutions.&lt;p&gt;The best way out of this is to subdivide responsibilities:&lt;p&gt;- Put all build&amp;#x2F;publish&amp;#x2F;test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well.  The only interaction between a test runner and the codebase should be running `make &amp;lt;target&amp;gt;`.&lt;p&gt;- Put all permissions and code checkout and artifact publishing credentials in the test runner, but no logic. At most you would put processing of test output like making junit&amp;#x2F;coverage&amp;#x2F;tap more web-readable.&lt;p&gt;That&amp;#x27;s it. Split the efforts cleanly, and things fall into place.  Also, you can switch runners easily - less needs to be reimplemented in whatever runner config DSL is picked.</text></item></parent_chain></comment><story><title>The worst thing about Jenkins is that it works (2019)</title><url>http://twitchard.github.io/posts/2019-06-21-life-is-too-short-for-jenkins.html</url></story>