在“使用BuildBot搭建持续集成环境”一文中我曾经说到：公司使用的mail服务器只支持SSL连接，而BuildBot似乎对SSL连接的支持有些问题，导致构建结果mail无法发送“。BuildBot实际上使用的是Twisted的mail库来发送邮件的，我下载了Twisted的一些mail发送的例子程序，并使用我的公司mail账户配置，但依旧发送失败。看来这个问题与Twisted的实现有关了。

这个问题已经折腾我许久了，难道非得让我去debug Twisted库？还好，今天我想到了另外一种方法：使用stunnel。原理是这样的：通过stunnel将非SSL连接转换为到公司mail服务器的SSL连接，通过stunnel建立的这条转化通道，mail发送的问题就应该可以解决了。想法归想法，实际上能否达到我的目标，还得通过试验验证。

首先我们需要在BuildBot的master服务器上安装stunnel。

在Ubuntu服务器上安装stunnel很简单，执行sudo apt-get install stunnel即可。不过今天我却遇到了问题，我的Ubuntu服务器版本是9.04，执行install时发现似乎所有源都不可用了。执行了多次还是这样，sudo apt-get update也无法更新了。突然想到也许是9.04的支持年限到了，到网上一查，果不其然：去年10月份Ubuntu 9.04就不在支持范围了。难道没有专门for老旧Ubuntu版本的源可以使用了吗？还好Ubuntu中文论坛上有答案：Ubuntu官方有一个源http://old-releases.ubuntu.com/ubuntu是专为已经过了支持期限的版本服务的。将/etc/apt/sources.list备份后打开，将下面内容贴到该文件中：

deb http://old-releases.ubuntu.com/ubuntu jaunty main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu jaunty-security main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu jaunty-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu jaunty-backports main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu jaunty-proposed main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu jaunty main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu jaunty-security main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu jaunty-updates main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu jaunty-backports main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu jaunty-proposed main restricted universe multiverse

保存后执行update，然后再重新install stunnel，这回一切OK了。

接下来，我们来配置stunnel。

我们先打开/etc/default/stunnel4，将其中的ENABLED配置项的值从0改为1，这样我们就允许stunnel在主机重启后可以被自动启动。

/etc/stunnel/stunnel.conf这个配置文件才是我们需要重点关注的。主要改动的配置项及说明如下：

; Use it for client mode
client = yes ; 我们使用的是stunnel的client模式，所以这里将no改为yes

; cert = /etc/stunnel/mail.pem ; 注释掉该行

; 打开debug模式以及log文件输出，便于我们在使用初期问题的查找
debug = 7
output = /var/log/stunnel4/stunnel.log

; 下面是关键配置，stunnel将接收本地到25端口的mail连接，并将该mail连接转换为到smtp.your_domain.com:465的SSL连接
[ssmtp]
accept  = 127.0.0.1:25
connect = smtp.your_domain.com:465

配置就是这些了。我们通过sudo /etc/init.d/stunnel4 start启动stunnel。如果你在启动时遇到问题，别忘了查看一下/var/log/stunnel4/stunnel.log中的内容，多数情况下你都会很快的发现问题所在。比如我第一次启动stunnel时就得到了如下错误信息：
[Failed: /etc/stunnel/stunnel.conf]
You should check that you have specified the pid= in you configuration file

这个错误信息可能会让你误以为是配置出现了错误，但通过查看log会发现，原来错误原因是25端口已经被占用了。占用25端口的程序是sendmail，停掉sendmail服务，再次启动stunnel，我们得到以下的成功信息：

Starting SSL tunnels: [Started: /etc/stunnel/stunnel.conf] stunnel.

最后，我们来测试一下stunnel是否可以真正解决我们的问题。修改BuildBot master的master.cfg中的mail发送配置：

c['status'].append(mail.MailNotifier(fromaddr="SENDER_MAIL_ADDR",
                                     extraRecipients=["RECIPIENT_MAIL_ADDR"],
                                     sendToInterestedUsers=False,
                                     useTls=False,
                                     relayhost="127.0.0.1",
                                     smtpUser='foo',
                                     smtpPassword='foo!',
                                     smtpPort=25))

有了stunnel，我们就可以使用非SSL连接来发送mail了，不过我们的buildbot连的是stunnel监听的本机25端口。

触发一次构建，稍等片刻，我的Thunderbird里就出现了BuildBot构建失败的提醒mail，我们成功了。

有了BuildBot搭建的持续集成环境还远未结束，具体的构建脚本还得自己来写。我们用的是Make工具，对应要编写的脚本就是Makefile。

Make是日常代码构建常用的工具，尤其是绝大多数C和C++项目都会将Make作为首选构建工具。平时多数情况大家都是直接敲入make命令便开始了构建过程，很少有人为make传入什么参数的（调试Makefile的情况除外）。但是有些时候自定义的Make命令行变量还是很有用处的，特别是在将Make与持续集成环境集成的时候。

实际上这个话题是源于我在搭建持续集成环境时遇到的一个实际问题。我们的产品的目标之一就是支持在不同平台上运行。这样我们需要在不同平台下都能进行构建，这也要求我们的Makefile可以自适应多种环境。以前的产品没有多平台运行的需求，其Makefile的实现也就没有考虑到这一点。在做平台移植的过程中，我们对Makefile脚本做了调整，不过虽然其可以满足在多平台上Build的要求，但是在某些情况下Build前需手工修改Makefile中的某些开关变量，比如是进行64bit编译还是32bit编译等。

这样的Makefile是不能用于持续集成环境下的多平台构建的，因为是自动构建，我们无法在中间进行人工干预。这时我们就需要借助Make命令行变量的帮助来解决这一问题了。举一个简单的例子，看下面的C源文件和对应的Makefile：

/* foo.c */
int main() {
    printf("sizeof(long) = %d\n", sizeof(long));
}

#
# Makefile
#

CMODE = 64-bit

ifeq ($(CMODE), 64-bit)
    CFLAGS += -m64
endif
   
all:
    gcc $(CFLAGS) -o foo foo.c   

显然Makefile中CMODE的取值不同，编译出的foo执行的结果就不同。但我们确有这样的需求，我们需要通过控制CMODE的值来决定Build结果。我们不想改动Makefile，我们可以通过Make的命令行变量设置来解决这个问题。我们只需在执行make时传入"CMODE=32-bit"这个参数即可让Build过程按照非64位方式进行。

一般的带命令行变量的make命令格式是：make [variable1=value1 variable2=value2 ... ... ]。make命令行中传入的变量会覆盖Makefile文件中定义的同名的并且没有使用override修饰的变量。命令行上的变量的赋值也可以用支持直接展开的:=赋值符号。

有了这种方法，我们就可以在BuildBot的build factory实例化时传入带参数的step了，即可以通过不同参数来控制在各个平台上的自动构建了。