blocks|key|2960908|text|首先，将鼠标悬停在下面的灰色区域上。不是答案的一部分，但绝对必须说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2960909|2960910|如果你有一个可以“签出、构建、部署”的shell脚本，那为什么还要用Jenkins呢？您放弃了Jenkins的所有特性，正是这些特性造就了Jenkins。您还可以使用cron或SVN+post-挂钩直接调用脚本。Jenkins执行SVN结帐本身是至关重要的。它允许只有在发生更改时才触发构建(如果您愿意，也可以在计时器上或手动触发)。它跟踪构建之间的更改。它显示了这些更改，因此您可以看到哪个构建是针对哪组更改的。当提交者的更改导致构建成功或失败时，它会向提交者发送电子邮件(同样，根据您的喜好进行配置)。它将向提交者发送电子邮件，当他们修复了失败的构建时。而且越来越多。Jenkins对工件进行归档也使它们在每次构建时都可以直接从Jenkins获得。虽然不像SVN结帐那么重要，但这再次成为了Jenkins的一个组成部分。部署也是如此。除非您只有一个环境，否则通常会在多个环境中进行部署。Jenkins可以通过使用Promotions来跟踪特定构建(具有特定SVN更改集)部署在哪个环境中。你放弃了这一切。听起来好像有人告诉你“你必须使用Jenkins”，但你并不是真的想这样做，而且你这样做只是为了让你的老板不再烦你，只是为了勾选“是的，我已经使用了Jenkins”。|blockquote|offset|length|style|BOLD|2960911|2960912|2960913|简短的答案是:Jenkin的的执行外壳构建步骤的最后一个命令的退出代码决定了构建步骤的成功/失败。0+-成功，anything+else+-失败。请注意，这决定了构建步骤的成败，而不是整个作业运行的成败。整个作业运行的成功/失败可能进一步受到多个构建步骤以及构建后操作和插件的影响。|CODE|2960914|您已经提到了Build+step+'Execute+shell'+marked+build+as+failure，所以我们将只关注一个构建步骤。如果Execute+shell构建步骤只有一行调用您的shell脚本，那么shell脚本的退出代码将决定构建步骤的成功或失败。如果您有更多的行，在您的shell脚本执行之后执行，然后仔细检查它们，因为它们是可能导致失败的那些行。|2960915|最后，请阅读此处的。它与您问题没有直接关系，但请注意Jenkins使用/bin/sh+-xe启动Execute+shell构建步骤的部分|2960916|-e意味着，即使只有一个命令失败，shell脚本也会退出，如果您对该命令执行错误检查，则会退出(因为脚本在执行错误检查之前就退出了)。这与shell脚本的正常执行相反，shell脚本通常会打印失败命令的错误消息(或将其重定向到null并通过其他方式处理)，然后继续执行。|2960917|要避免此问题，请将set+%2Be添加到shell脚本的顶部。|2960918|既然您说您的脚本完成了它应该做的所有事情，那么失败的命令很可能就在脚本的末尾。也许是最后一个回声？或者是某个地方的文物复制品？在没有看到完整的控制台输出的情况下，我们只是猜测。|2960919|请发布作业运行的控制台输出，最好是shell脚本本身，然后我们可以准确地告诉您哪一行失败了。|2960920|entityMap^0|0|0|2P|8|0|0|0|E|E|12|4|29|4|1D|1|1J|D|0|6|1E|22|D|4G|Q|0|0|1W|Z|B|0|0|1B|0|2|0|9|6|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|14|8|@$F|15|G|16|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|19|8|@$F|1A|G|1B|H|I]|$F|1C|G|1D|H|I]|$F|1E|G|1F|H|I]|$F|1G|G|1H|H|N]|$F|1I|G|1J|H|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1K|8|@$F|1L|G|1M|H|N]|$F|1N|G|1O|H|I]|$F|1P|G|1Q|H|I]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1R|8|@$F|1S|G|1T|H|I]|$F|1U|G|1V|H|N]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1W|8|@$F|1X|G|1Y|H|I]|$F|1Z|G|20|H|N]]|9|@]|A|$]]|$1|U|3|V|5|6|7|21|8|@$F|22|G|23|H|N]]|9|@]|A|$]]|$1|W|3|X|5|6|7|24|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|25|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|26|8|@]|9|@]|A|$]]]|11|$]]

First things first, hover the mouse over the grey area below. Not part of the answer, but absolutely has to be said:

<blockquote>
 If you have a shell script that does "checkout, build, deploy" all by itself, then why are you using Jenkins? You are foregoing all the features of Jenkins that make it what it is. You might as well have a cron or an SVN post-commit hook call the script directly. Jenkins performing the SVN checkout itself is crucial. It allows the builds to be triggered only when there are changes (or on timer, or manual, if you prefer). It keeps track of changes between builds. It shows those changes, so you can see which build was for which set of changes. It emails committers when their changes caused successful or failed build (again, as configured as you prefer). It will email committers when their fixes fixed the failing build. And more and more. Jenkins archiving the artifacts also makes them available, per build, straight off Jenkins. While not as crucial as the SVN checkout, this is once again an integral part of what makes it Jenkins. Same with deploying. Unless you have a single environment, deployment usually happens to multiple environments. Jenkins can keep track of which environment a specific build (with specific set of SVN changes) is deployed it, through the use of Promotions. You are foregoing all of this. It sounds like you are told "you have to use Jenkins" but you don't really want to, and you are doing it just to get your bosses off your back, just to put a checkmark "yes, I've used Jenkins"
</blockquote>

The short answer is: the exit code of last command of the Jenkin's Execute Shell build step is what determines the success/failure of the Build Step. <code>0</code> - success, <code>anything else</code> - failure.
Note, this is determining the success/failure of the build step, not the whole job run. The success/failure of the whole job run can further be affected by multiple build steps, and post-build actions and plugins.

You've mentioned <code>Build step 'Execute shell' marked build as failure</code>, so we will focus just on a single build step. If your Execute shell build step only has a single line that calls your shell script, then the exit code of your shell script will determine the success/failure of the build step. If you have more lines, after your shell script execution, then carefully review them, as they are the ones that could be causing failure.

Finally, have a read here <a href="https://stackoverflow.com/questions/13400445/jenkins-build-script-exits-after-google-test-execution/13404608#13404608">Jenkins Build Script exits after Google Test execution</a>. It is not directly related to your question, but note that part about Jenkins launching the Execute Shell build step, as a shell script with <code>/bin/sh -xe</code>

The <code>-e</code> means that the shell script will exit with failure, even if just 1 command fails, even if you do error checking for that command (because the script exits before it gets to your error checking). This is contrary to normal execution of shell scripts, which usually print the error message for the failed command (or redirect it to null and handle it by other means), and continue.

To circumvent this, add <code>set +e</code> to the top of your shell script.

Since you say your script does all it is supposed to do, chances are the failing command is somewhere at the end of the script. Maybe a final echo? Or copy of artifacts somewhere? Without seeing the full console output, we are just guessing.

Please post the job run's console output, and preferably the shell script itself too, and then we could tell you exactly which line is failing.

blocks|key|2748276|text|简单明了：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2748277|如果Jenkins看到构建步骤(这也是一个脚本)以非零代码退出，则构建会标有一个红色的球(=+failed)。|2748278|发生这种情况的确切原因取决于您的构建脚本。|2748279|我从另一个角度写了一些类似的东西，但也许阅读它会有所帮助：Why+does+Jenkins+think+my+build+succeeded?|offset|length|2748280|entityMap|0|LINK|mutability|MUTABLE|url|http://thingsyoudidntknowaboutjenkins.tumblr.com/post/30255425955/why-does-jenkins-think-my-build-succeeded^0|0|0|0|T|16|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Plain and simple:

If Jenkins sees the build step (which is a script too) exits with non-zero code, the build is marked with a red ball (= failed).

Why exactly that happens depends on your build script.

I wrote something similar from another point-of-view but maybe it will help to read it anyway:
<a href="http://thingsyoudidntknowaboutjenkins.tumblr.com/post/30255425955/why-does-jenkins-think-my-build-succeeded" rel="nofollow">Why does Jenkins think my build succeeded?</a>

blocks|key|157094|text|对你的问题的简单简短的回答是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|157095|请将以下代码行添加到“执行shell”构建步骤中。|157096|#!/bin/sh|code-block|syntax|javascript|157097|现在让我向您解释为什么我们需要“执行Shell”构建作业的这一行。|157098|默认情况下，Jenkins使用/bin/sh+-xe，这意味着-x将打印每个command.And的另一个选项-e，当任何命令以非零(当任何命令失败)退出时，这会导致外壳立即停止运行脚本。|offset|length|style|CODE|157099|因此，通过添加#!/bin/sh将允许您在没有选项的情况下执行。|157100|entityMap^0|0|0|0|0|F|B|V|2|1J|2|0|7|9|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]|$M|11|N|12|O|P]|$M|13|N|14|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@$M|16|N|17|O|P]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|T|$]]

Simple and short answer to your question is

Please add following line into your "Execute shell" Build step.

<pre><code>#!/bin/sh
</code></pre>

Now let me explain you the reason why we require this line for "Execute Shell" build job.

By default Jenkins take <code>/bin/sh -xe</code> and this means <code>-x</code> will print each and every command.And the other option <code>-e</code>, which causes shell to stop running a script immediately when any command exits with non-zero (when any command fails) exit code. 

So by adding the <code>#!/bin/sh</code> will allow you to execute with no option.

blocks|key|2748326|text|在我看来，关闭shell的-e选项是一个非常糟糕的主意。最终，脚本中的某个命令将由于磁盘空间不足或网络错误等瞬时条件而失败。如果没有-e，Jenkins就不会注意到这一点，并会愉快地继续下去。如果你已经设置了Jenkins来做部署，这可能会导致糟糕的代码被推送，并使你的网站瘫痪。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2748327|如果脚本中有一行预期会失败的行，比如grep或find，那么只需在该行的末尾添加%7C%7C+true即可。这确保了这一行总是返回成功。|2748328|如果需要使用退出代码，可以将命令放入If语句中：|2748329|grep+foo+bar;+if+[+$?+==+0+];+then+...++++-->+++if+grep+foo+bar;+then+...|code-block|syntax|javascript|2748330|或者，您可以在%7C%7C子句中捕获返回代码：|2748331|grep+foo+bar+%7C%7C+ret=$?|2748332|entityMap^0|D|2|1U|2|0|14|7|0|0|0|7|2|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|12|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|13|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|L|7|17|8|@]|D|@]|E|$M|N]]|$1|S|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|T|$]]

In my opinion, turning off the <code>-e</code> option to your shell is a really bad idea. Eventually one of the commands in your script will fail due to transient conditions like out of disk space or network errors. Without <code>-e</code> Jenkins won't notice and will continue along happily. If you've got Jenkins set up to do deployment, that may result in bad code getting pushed and bringing down your site.

If you have a line in your script where failure is expected, like a grep or a find, then just add <code>|| true</code> to the end of that line. That ensures that line will always return success.

If you need to use that exit code, you can either hoist the command into your if statement:

<pre><code>grep foo bar; if [ $? == 0 ]; then ... --&gt; if grep foo bar; then ...
</code></pre>

Or you can capture the return code in your <code>||</code> clause:

<pre><code>grep foo bar || ret=$?
</code></pre>

blocks|key|2748378|text|因此，通过添加#!/bin/sh将允许您在没有选项的情况下执行。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2748379|它还帮助我修复了一个问题，即我在我的Linux从服务器上执行来自Jenkins主机的bash脚本。通过在“执行外壳”块中添加#!/bin/bash到我的实际脚本之上，它修复了我的问题，否则它就会执行windows+git提供的bash+shell版本，这会给出一个错误。|2748380|entityMap^0|7|9|0|1Q|B|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

So by adding the <code>#!/bin/sh</code> will allow you to execute with no option.

It also helped me in fixing an issue where I was executing bash script from Jenkins master on my Linux slave. By just adding <code>#!/bin/bash</code> above my actual script in "Execute Shell" block it fixed my issue as otherwise it was executing windows git provided version of bash shell that was giving an error.

blocks|key|158281|text|在Jenkins版本。1.635，则不可能像这样显示本机环境变量：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|158282|$BUILD_NUMBER+or+${BUILD_NUMBER}|code-block|syntax|javascript|158283|在这种情况下，您必须在另一个变量中设置它。|158284|set+BUILDNO+=+$BUILD_NUMBER
$BUILDNO|158285|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

In Jenkins ver. 1.635, it is impossible to show a native environment variable like this:

<pre><code>$BUILD_NUMBER or ${BUILD_NUMBER}
</code></pre>

In this case, you have to set it in an other variable.

<pre><code>set BUILDNO = $BUILD_NUMBER
$BUILDNO
</code></pre>

blocks|key|2961023|text|我已经尝试了上面提到的所有选项(甚至在没有-xe参数的情况下将sh更改为bash+)，唯一对我有效的选项是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2961024|<command-which-returns-not-zero>+%7C%7C+exit+0|code-block|syntax|javascript|2961025|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I 've tried all mentioned options (even changing sh to bash without -xe params), the only one option worked for me is:
<pre><code>&lt;command-which-returns-not-zero&gt; || exit 0
</code></pre>

The horror stories I found while searching for an answer for this one...

OK, I have a .sh script which pretty much does everything Jenkins supposed to do:

<ul>
<li>checks out sources from SVN</li>
<li>build the project</li>
<li>deploys the project</li>
<li>cleans after itself</li>
</ul>

So in Jenkins I only have to 'build' the project by running the script in an Execute Shell command.
 The script is ran (the sources are downloaded, the project is build/deploy) but then it marks the build as a failure:
Build step 'Execute shell' marked build as failure
Even if the script was successfully ran! I tried closing the script with:

<ul>
<li>exit 0 (still marks it as failure)</li>
<li>exit 1 (marks it as failure, as expected)</li>
<li>no exit command at all (marks it as failure)</li>
</ul>

When, how and why does Execute Shell mark my build as a failure?

How/When does Execute Shell mark a build as failure in Jenkins?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在寻找答案时发现的恐怖故事...好了，我有一个.sh脚本，它几乎完成了Jenkins应该做的所有事情：从SVN中签出源代码构建项目在之后清理自己的项目因此，在Jenkins中，我只需通过在Execute Shell命令中运行脚本来“构建”项目。脚本已运行(源代码已下载，项目已构建/部署)，但随后它会将构建标记为失败:...

问在Jenkins中，如何/何时执行Shell将构建标记为失败？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Jenkins中，如何/何时执行Shell将构建标记为失败？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Jenkins中，如何/何时执行Shell将构建标记为失败？
EN