metasploit-framework/.travis.yml

language: ruby
before_install:
  - rake --version
  - sudo apt-get update -qq
  - sudo apt-get install -qq libpcap-dev
  # Uncomment when we have fewer shipping msftidy warnings.
  # Merge committers will still be checking, just not autofailing.
  # See https://dev.metasploit.com/redmine/issues/8498
  # - ln -sf ../../tools/dev/pre-commit-hook.rb ./.git/hooks/post-merge
  # - ls -la ./.git/hooks
  # - ./.git/hooks/post-merge
before_script:
  - cp config/database.yml.travis config/database.yml
  - bundle exec rake --version
  - bundle exec rake db:create
  - bundle exec rake db:migrate

rvm:
  #- '1.8.7'
  - '1.9.3'

notifications:
  irc: "irc.freenode.org#msfnotify"

git:
  depth: 5
travis-ci.org integration Add the .travis.yml so that travis-ci.org knows which rubies (1.8.7 and 1.9.3 to run rake against. Add the build status button to the README.md so that people can see if the specs are passing from the main rapid7/metasploit-framework page on github just like other open source projects. 2012-11-07 15:29:44 +01:00			`language: ruby`
Make travis install libpcap-dev 2013-02-19 22:41:31 +01:00			`before_install:`
Don't try to bundle exec before bundle install 2014-01-06 19:47:36 +01:00			`- rake --version`
Make travis install libpcap-dev 2013-02-19 22:41:31 +01:00			`- sudo apt-get update -qq`
			`- sudo apt-get install -qq libpcap-dev`
Travis shouldn't autofail msftidy fails... yet [SeeRM #8498] 2014-04-08 21:05:17 +02:00			`# Uncomment when we have fewer shipping msftidy warnings.`
			`# Merge committers will still be checking, just not autofailing.`
			`# See https://dev.metasploit.com/redmine/issues/8498`
			`# - ln -sf ../../tools/dev/pre-commit-hook.rb ./.git/hooks/post-merge`
			`# - ls -la ./.git/hooks`
			`# - ./.git/hooks/post-merge`
Can we test the modules before the bundle install? 2014-04-03 17:41:42 +02:00			`before_script:`
Configure travis-ci to use database for rake spec [#46224565] 2013-03-15 14:48:20 +01:00			`- cp config/database.yml.travis config/database.yml`
Add bundle exec rake to avoid system rake 2014-01-06 19:29:50 +01:00			`- bundle exec rake --version`
			`- bundle exec rake db:create`
			`- bundle exec rake db:migrate`
Make travis install libpcap-dev 2013-02-19 22:41:31 +01:00
travis-ci.org integration Add the .travis.yml so that travis-ci.org knows which rubies (1.8.7 and 1.9.3 to run rake against. Add the build status button to the README.md so that people can see if the specs are passing from the main rapid7/metasploit-framework page on github just like other open source projects. 2012-11-07 15:29:44 +01:00			`rvm:`
STFU, travis 2013-01-10 20:53:47 +01:00			`#- '1.8.7'`
Disable CI testing on 1.8.7 for now To stop the flood of everything-is-broken emails 2012-11-08 03:53:55 +01:00			`- '1.9.3'`
Add IRC notifications and allow 1.8.7 to fail This should tell travis to run the tests against 1.8.7 but not to consider the whole build broken if it fails (which it currently does) 2012-11-09 22:02:09 +01:00
			`notifications:`
			`irc: "irc.freenode.org#msfnotify"`

Attempt to make travis useful again Lowers the history depth from the default of 100. 2013-01-24 22:48:04 +01:00			`git:`
Extend Travis's depth a bit Instead of depth=1, try depth=5. This way, if something gets landed before travis had a chance to build, it'll still get tested, at least post-facto. This is the root cause of the build failure at https://travis-ci.org/rapid7/metasploit-framework/builds/11436293 That commit is not available because the HEAD pointer moved past it with the next commit; IOW, we landed too quick for Travis to rspec each change, which is generating failed build messages. If there was really a failure in there, it'd be a pain now to determine which commit actually broke the build. 2013-09-17 00:23:16 +02:00			`depth: 5`