使 Jenkins 'Execute Shell' 与使用 bash shell 时完全相同
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/20316685/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Make Jenkins 'Execute Shell' exactly the same as when using bash shell
提问by Sam Jarman
So I've come across a few things now that seem to just not work right in the jenkins 'Execute shell' stage of a build. These works fine when logged in as the same user on the same machine when typing into bash/zsh/terminal.
所以我现在遇到了一些在构建的 jenkins 'Execute shell' 阶段似乎无法正常工作的事情。当在同一台机器上以同一用户身份登录 bash/zsh/terminal 时，这些工作正常。
Is there some setting somewhere to make these match exactly, in terms of permissions, output etc... seems like Jenkins is in some sort of weird sandbox and its really frustrating.
在权限、输出等方面，是否有一些设置可以使这些完全匹配……看起来 Jenkins 处于某种奇怪的沙箱中，这真的令人沮丧。
A few things that have tripped so far is ruby commands like
到目前为止，一些失败的事情是 ruby 命令，例如
bundle exec nanoc compile
and
和
cap deploy
Any ideas would be appreciated!
任何想法，将不胜感激！
More info: Jenkins is running on Mac OSX Mavericks.
更多信息：Jenkins 在 Mac OSX Mavericks 上运行。
回答by Charles Duffy
This is a situation where details matter.
在这种情况下，细节很重要。
The most common case where commands work during interactive testing but fail when run from a service is a simple dependency on environment variables, dotfiles, file permissions, and similar setup.
命令在交互式测试期间工作但从服务运行时失败的最常见情况是对环境变量、点文件、文件权限和类似设置的简单依赖。
You can test as the user you're running Jenkins under using su - jenkins(presuming a user named "jenkins"). Next, check the environment variables in-scope for your runtime environment; one way to do this is simply running the envcommand inside your Jenkins job, then using env -i K1=V1 K2=V2 ... your-commandto simulate that same environment within your tests.
您可以使用运行 Jenkins 的用户身份进行测试su - jenkins（假设用户名为“jenkins”）。接下来，检查运行时环境范围内的环境变量；一种方法是简单地env在您的 Jenkins 作业中运行该命令，然后env -i K1=V1 K2=V2 ... your-command在您的测试中使用它来模拟相同的环境。
Finally, be sure that the shell being used to test is the same one being used at runtime. If Jenkins is starting /bin/sh, you need to test with /bin/sh-- not /bin/bash(even if /bin/shis a symlink to bash!), and certainly not zsh.
最后，确保用于测试的 shell 与运行时使用的 shell 相同。如果詹金斯开始/bin/sh，你需要与测试/bin/sh-不/bin/bash（即使/bin/sh是一个符号链接bash！），当然也不是zsh。
If your failure cases are interesting enough, though, you may be hitting OS-level security frameworks. There's no way to determine that without precise details on the failures, which are not given here (and aren't really topical on StackOverflow anyhow; this would be a question for ServerFault or such if you were hitting restrictions of that type). Your system administration staff are the best folks to help here.
但是，如果您的失败案例足够有趣，那么您可能会遇到操作系统级别的安全框架。如果没有关于失败的精确细节，就无法确定，这里没有给出这些细节（无论如何都不是 StackOverflow 上的主题；如果你遇到了这种类型的限制，这将是 ServerFault 或类似的问题）。您的系统管理人员是在这里提供帮助的最佳人选。
