Gitlab 日志查看

我们可以用gitlab-ctl tail 命令查看实时log。

Runit-managed是一个跨平台的用来取代Linux系统默认的服务控制的一个init系统， 想要了解更多知识，请自行搜索runit及sysvinit的相关信息。

omnibus-gitlab生成logs用的Runit-managed服务是svlogd， 关于svlogd的详细介绍， 请查看svlogd documentation。

修改/etc/gitlab/gitlab.rb文件里面如下参数可以自定义svlogd:

Omnibus-gitlab从7.4版本开始内置了logrotate服务。 这个服务用来切割、 压缩并最终删除已不受Runit服务(即上节里面的svlogd)控制的日志文件， 如gitlab-rails/production.log、nginx/gitlab_access.log。 你可以根据需求修改/etc/gitlab/gitlab.rb中logrotate的参数。

UDP log shipping (GitLab Enterprise Edition only)

Omnibus-gitlab企业版可以配置使用UDP传输歼孙祥syslog-ish日志凯纯信息。

log messages实例:

Nginx的access日志默认使用'combined'格式化日志， 查看nginx日志格式。 如果你想氏搏用自定义日志的格式， 修改/etc/gitlab/gitlab.rb 文件如下的参数:

上面说纤神皮的有点不清楚。默认情况下，每一个对 assets 的请求，会产生两行日志：

```Started GET "/assets/...

Served asset /...

其中，第1行是 ActionPack 输出的（Rails rack logger），第二行是 Sprockets 输出的。

3.2 中增加的选项是用来把 Sprockets 的输出关闭（config.assets 用来控制 Sprockets）。而对于 Rails 本身来说，`Started GET...` 那一行跟其他普通请求的日志是一毁差样的，不应该区别对待。

上面那个 Gem 做的，就是判断路径，是 "/assets" 的就瞎野消掉。（不过要注意 assets 路径其实是可以定制的。所以 Rails logger 跟 Sprockets 都没办法靠自身来处理这个问题：）

第一步 安装rspec和rspec-rails在命令行中执行如下命令：

$ sudo gem install rspec v = 1.3.0

$ sudo gem install rspec-rails v = 1.3.2

安装完成后，进入rails应用所在的目录，运行如下脚本，生成spec测试框架：

$ script/generate rspec

exists lib/tasks

identical lib/tasks/rspec.rake

identical script/autospec

identical script/spec

exists spec

identical spec/rcov.opts

identical spec/spec.opts

identical spec/spec_helper.rb

第二步 安装factory-girl在命令行中执行如下命令：

相关厂商内容

百度研究院高级科学家谈大规模机器学习技术 天猫前端开发专家鬼和祥者道解读Native 和 Web 融合 《深入浅出Node.js》作者朴灵主持QCon全栈开发专题 知乎联合创始人兼 CTO出品QCon知名移动案例专题 “伤筋动骨一百天”-大型组织唤薯转型实例剖析 相关赞助商

全球软件开发大会，4月23-25日，北京，敬请期待！

$ sudo gem install factory-girl

在config/environment/test.rb中，加入factory-girl这个gem：

config.gem "factory_girl"

在spec/目录下，增加一个factories.rb的文件，用于所有预先定义的model工厂。

第三步 安装autotest在命令行中执行如下命令：

$ sudo gem install ZenTest

$ sudo gem install autotest-rails

然后设置与RSpec的集成，在rails应用的目录下，运行如下的命令，就可以显示测试用例的运行结果。

RSPEC=true autotest or autospec

在自己的home目录下，增加一个.autotest设置所有的Rails应用的autotest插件。当然，也可以把这个文件加到每个应用的根目录下，这个文件将覆盖home目录下宴清的文件设置。autotest的插件很多，笔者用到如下的plugin：

$ sudo gem install autotest-growl

$ sudo gem install autotest-fsevent

$ sudo gem install redgreen

设置.autotest文件，在.autotest中，加入如下代码。

require 'autotest/growl'

require 'autotest/fsevent'

require 'redgreen/autotest'

Autotest.add_hook :initialize do |autotest|

%w{.git .svn .hg .DS_Store ._* vendor tmp log doc}.each do |exception|

autotest.add_exception(exception)

end

end

测试经验安装了必要的程序库以后，就可以写测试代码了。本例中，所有应用都是在Rails 2.3.4上开发的，RSpec采用的是1.3.0的版本。为了很好的说明问题，我们假定这样的需求：判断一个用户在一个时间段内是否迟到。写测试代码时都是遵循一个原则，只关心输入和输出，具体的实现并不在测试代码的考虑范围之内，是行为驱动开发。根据这个需求，我们将会设计方法absence_at(start_time,end_time)，有两个输入值start_time和end_time以及一个输出值，类型是boolean。对应的测试代码如下：

describe "User absence or not during [start_time,end_time]" do

before :each do

@user = Factory(:user)

end

it "should return false when user not absence " do

start_time = Time.utc(2010,11,9,12,0,0,0)

end_time = Time.utc(2010,11,9,12,30,0)

@user.absence_at(start_time,end_time).should be_false

end

it "should return true when user absence " do

start_time = Time.utc(2010,11,9,13,0,0,0)

end_time = Time.utc(2010,11,9,13,30,0)

@user.absence_at(start_time,end_time).should be_ture

end

end

测试代码已经完成。至于absence_at方法我们并不关心它的实现，只要这个方法的结果能让测试代码运行结果正确就可以。在此测试代码的基础上，就可以大胆地去完成代码，并根据测试代码的结果不断修改代码直到所有测试用例通过。

Stub的使用写测试代码，最好首先从model开始。因为model的方法能很好与输入输出的原则吻合，容易上手。最初的时候，你会发现mock和stub很好用，任何的对象都可以mock，并且在它的基础上可以stub一些方法，省去构造数据的麻烦，一度让笔者觉得测试代码是如此美丽，一步步的深入，才发现自己陷入了stub的误区。还是引用上面的例子，我们的代码实现如下：

class User <ActiveRecord::Base

def absence_at(start_time,end_time)

return false if have_connection_or_review?(start_time,end_time)

return (login_absence_at?(start_time,end_time) ? true : false)

end

end

按照最初写测试代码的思路，本方法中存在三种情况，即需要三个用例，而且还调用了其他两个方法，需要对他们进行stub，于是就有了下面的测试代码。记得当时完成后还很兴奋，心中还想：这么写测试代码真有趣。

before(:each) do

@user = User.new

end

describe "method <absence_at(start_time,end_time)>" do

s = Time.now

e = s + 30.minutes

# example one

it "should be false when user have interaction or review" do

@user.stub!(:have_connection_or_review?).with(s,e).and_return(true)

@user.absence_at(s,e).should be_false

end

# example two

it "should be true when user has no interaction and he no waiting at platform" do

@user.stub!(:have_connection_or_review?).with(s,e).and_return(false)

@user.stub!(:login_absence_at?).with(s,e).and_return(true)

@user.absence_at(s,e).should be_true

end

# example three

it "should be false when user has no interaction and he waiting at platform" do

@user.stub!(:have_connection_or_review?).with(s,e).and_return(false)

@user.stub!(:login_absence_at?).with(s,e).and_return(false)

@user.absence_at(s,e).should be_false

end

end

上面的测试代码，是典型把代码的实现细节带到了测试代码中，完全是本末倒置的。当然这个测试代码运行的时候，结果都是正确的。那是因为用stub来假定所有的子方法都是对的，但是如果这个子方法have_connection_or_review?发生变化，它不返回boolean值，那么将会发生什么呢？这个测试代码依然正确，可怕吧！这都没有起到测试代码的作用。

另外，如果是这样，我们不仅要修改have_connection_or_review?的测试代码，而且还要修改absence_at的测试代码。这不是在增大代码维护量吗？

相比而言，不用stub的测试代码，不用修改，如果Factory的数据没有发生变化，那么测试代码的结果将是错误的，因为have_connection_or_review?没有通过测试，导致absence_at方法无法正常运行。

其实stub主要是mock一些本方法或者本应用中无法得到的对象，比如在tech_finish?方法中，调用了一个file_service来获得Record对象的所有文件，在本方法测试代码运行过程中，无法得到这个service，这时stub就起作用了：

class A <ActiveRecord::Base

has_many :records

def tech_finish?

self.records.each do |v_a|

return true if v_a.files.size == 5

end

return false

end

end

class Record <ActiveRecord::Base

belongs_to :a

has_files # here is a service in gem

end

所对应的测试代码如下：

describe "tech_finish?" do

it "should return true when A’s records have five files" do

record = Factory(:record)

app = Factory(:a,:records=>[record])

record.stub!(:files).and_return([1,2,3,4,5])

app.tech_finish?.should == true

end

it "should return false when A’s records have less five files" do

record = Factory(:record)

app = Factory(:a,:records=>[record])

record.stub!(:files).and_return([1,2,3,5])

app.tech_finish?.should == false

end

end

Factory的使用有了这个工厂，可以很方便的构造不同的模拟数据来运行测试代码。还是上面的例子，如果要测试absence_at方法，涉及到多个model：

•HistoryRecord：User的上课记录

•Calendar：User的课程表

•Logging：User的日志信息

如果不用factory-girl构造测试数据，我们将不得不在fixture构造这些测试数据。在fixture构造的数据无法指定是那个测试用例使用，但是如果用Factory的话，可以为这个方法专门指定一组测试数据。

Factory.define :user_absence_example,:class =>User do |user|

user.login "test"

class <<user

def default_history_records

[Factory.build(:history_record,:started_at=>Time.now),

Factory.build(:history_record,:started_at=>Time.now)]

end

def default_calendars

[Factory.build(:calendar),

Factory.build(:calendar)]

end

def default_loggings

[Factory.build(:logging,:started_at=>1.days.ago),

Factory.build(:logging,:started_at=>1.days.ago)]

end

end

user.history_records {default_history_records}

user.calendars {default_calendars}

user.loggings {default_loggings}

end

这个测试数据的构造工厂，可以放在factories.rb文件中，方便其他测试用例使用，也可以直接放到测试文件的before中，仅供本测试文件使用。通过factory的构造，不仅可以为多个测试用例共享同一组测试数据，而且测试代码也简洁明了。

before :each do

@user = Factory.create(:user_absence_example)

end

---