appelier / bigtuna

Continuous Integration software written on top of Ruby on Rails 3 and DelayedJob.

About

BigTuna is a continuous integration software built on top of the Rails 3 framework. It aims to be project—agnostic and extendible.

Find out more on https://bigtuna-site.herokuapp.com

Contributors

BigTuna was created by Michał Bugno and Antek Piechnik. The following people have kindly contributed to make it a better project:

• David Rouchy
• François Lamontagne
• Víctor Martínez
• unsay
• Jonathan Dance
• Pawel Obrok
• Pawel Pierzchala
• …and others (some mentioned in the pull request * list)

Build Status

License

Copyright (c) 2010  Michal Bugno, Antek Piechnik

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

bigtuna's Issues

Starting BigTuna fails on MacOS X

Got this error when trying to start rails server on a freshly cloned BigTuna repository on Mac OS X (10.6.5):

/Library/Ruby/Gems/1.8/gems/linecache-0.43/lib/../lib/trace_nums.bundle: dlopen(
/Library/Ruby/Gems/1.8/gems/linecache-0.43/lib/../lib/trace_nums.bundle, 9): no suitable image found.  Did find: (LoadError)
/Library/Ruby/Gems/1.8/gems/linecache-0.43/lib/../lib/trace_nums.bundle: no matching architecture in universal wrapper - /Library/Ruby/Gems/1.8/gems/linecache-0.43/lib/../lib/trace_nums.bundle
...

Autotest can´t run

I can´t run autotest, a have the next error:

$ autotest
loading autotest/rails
/Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/bin/ruby -I.:lib:test -rubygems -e "%w[test/unit test/unit/mercurial_vcs_test.rb test/unit/build_part_test.rb test/unit/helpers/application_helper_test.rb test/unit/helpers/step_lists_helper_test.rb test/integration/builds_test.rb test/unit/project_test.rb test/unit/hooks_test.rb test/unit/git_vcs_test.rb test/unit/xmpp_hook_test.rb test/unit/irc_hook_test.rb test/integration/projects_test.rb test/unit/build_test.rb test/unit/step_list_test.rb test/integration/hooks_test.rb test/integration/autobuild_test.rb test/unit/mailer_hook_test.rb test/integration/step_list_test.rb].each { |f| require f }" | unit_diff -u
/Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/activesupport-3.0.3/lib/active_support/dependencies.rb:239:in `require': no such file to load -- context (LoadError)
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/activesupport-3.0.3/lib/active_support/dependencies.rb:239:in `require'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/activesupport-3.0.3/lib/active_support/dependencies.rb:225:in `load_dependency'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/activesupport-3.0.3/lib/active_support/dependencies.rb:596:in `new_constants_in'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/activesupport-3.0.3/lib/active_support/dependencies.rb:225:in `load_dependency'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/activesupport-3.0.3/lib/active_support/dependencies.rb:239:in `require'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/shout-bot-0.0.4/./shout-bot.rb:81
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler/runtime.rb:64:in `require'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler/runtime.rb:64:in `require'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler/runtime.rb:62:in `each'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler/runtime.rb:62:in `require'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler/runtime.rb:51:in `each'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler/runtime.rb:51:in `require'
    from /Users/ceritium/.rvm/gems/ruby-1.8.7-p248/gems/bundler-1.0.3/lib/bundler.rb:112:in `require'
    from /Users/ceritium/work/bigtuna/config/application.rb:7
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /Users/ceritium/work/bigtuna/config/environment.rb:2
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from ./test/test_helper.rb:2
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from ./test/unit/mercurial_vcs_test.rb:1
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from /Users/ceritium/.rvm/rubies/ruby-1.8.7-p248/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from -e:1
    from -e:1:in `each'
    from -e:1

I have tried to install the gem 'context' but i have the same response.

¿Someone have the same problem?

BigTuna assumes version of git

Running BigTuna on an Ubuntu VM, I get:

dbalatero@ci ~/bigtuna (master) % git --version
git version 1.6.3.3
dbalatero@ci ~/bigtuna (master) % git clone --branch master --depth 1 [email protected]:mediapiston/myrepo.git /home/dbalatero/bigtuna/builds/myrepo/build_6_20101209200201
error: unknown option `branch'

However, on OS X, with:

dbalatero@lando ~ % git --version
git version 1.6.6.1

It works ok.

Maybe you should define the minimum Git version that supports the --branch feature in the docs?

Feature: IRC and Campfire notifications would be great

Email notifications are great but group chat notifications (IRC, Campifire, Partychat) would be very nice to have.

Btw, I had a look at the code and I really like how you kept everything clean and simple. Great job!

Environment does not get inherited

When I run rake through big tuna, I get an error, where the environment does not seem to get loaded:

bundle exec rake --trace

Exit code: 1
(in /var/www/bigtuna/shared/builds/data_wrangler/build_8_20110223042027)
rake aborted!
no such file to load -- sinatra
/var/www/bigtuna/shared/builds/data_wrangler/build_8_20110223042027/lib/web_api.rb:1:in `require'
/var/www/bigtuna/shared/builds/data_wrangler/build_8_20110223042027/lib/web_api.rb:1
./lib/initializer.rb:26:in `require'
./lib/initializer.rb:26
/var/www/bigtuna/shared/builds/data_wrangler/build_8_20110223042027/Rakefile:4:in `require'
/var/www/bigtuna/shared/builds/data_wrangler/build_8_20110223042027/Rakefile:4
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/bin/rake:31
/var/www/bigtuna/shared/bundle/ruby/1.8/bin/rake:19:in `load'
/var/www/bigtuna/shared/bundle/ruby/1.8/bin/rake:19

However, if I ssh into the box, cd into the build folder and run rake, everything works as expected.

Here is my build steps (I've tried with and without the commented bundle install line, with the same results):

# bundle install --path=%project_dir%/bundle --deployment --gemfile=%build_dir%/Gemfile
bundle install --path=%project_dir%/bundle --gemfile=%build_dir%/Gemfile
cd %build_dir%
cp examples/config/* config/
bundle exec rake --trace

Shared ENV variables for project.

wuputah raised a valid issue for sharing some ENV variables in every step of a project. This might be useful for example in setting GEMFILE_PATH or RAILS_ENV.

projects table, etc. getting purged

Something I noticed: the projects that I've configured are getting deleted after a certain number of minutes - the builds directory is still there, but the database looks like it has been purged.

Doing a select count(*) on the following tables return 0:

+-------------------+
| build_parts       | 
| builds            | 
| delayed_jobs      | 
| hooks             | 
| projects          | 
| shared_variables  | 
| step_lists        | 
+-------------------+

While the following, return some values (presumably because of previous build runs, etc):

| schema_migrations | 
| sessions          | 

The instance of bigtuna that I have running is configured to use MySQL, under Ruby 1.9.1

Is anyone else experiencing this?

Configurable build directory

Ability to change from the default of "builds/" - particularly needed for Heroku, where builds must take place in "tmp".

Also need to make sure that we don't "mkdir_p" this directory unnecessarily, since that invokes some read only errors on Heroku.

[This is a new feature I am already working on, adding it here for visibility.]

Build multiple branches

My company follows a "master stable" mentality, so something only gets merged to master once it gets shipped to production. As such, development is done on feature branches; however this means, we would have to create a new project for each feature.
Is there any development underway to have bigtuna test multiple branches? Something like "POST to http://big.tuna.host/hooks/build/:hook_name:/:branch_name: to build automatically"
I'm going to start development on this, but if someone has already started this effort or has any suggestions, I would love to hear it.

hudson-like git strategy

Guys, great app :)

Have you considered changing the checkout/clone strategy from the current cloning to new directories to the one hudson uses? It is faster (just one repo with git fetch) and more "git-like". Here is how it works:
[workspace] $ git fetch -t [email protected]:xxx/xxx.git +refs/heads/:refs/remotes/origin/
[workspace] $ git ls-tree HEAD
[workspace] $ git tag -l master
[workspace] $ git rev-parse origin/master
Commencing build of Revision xxxx (origin/master)
GitAPI created
Checking out Revision xxxx (origin/master)
[workspace] $ git checkout -f xxxx
[workspace] $ git tag -a -f -m "Hudson Build 143" hudson-xxxx_staging-143
Recording changes in branch origin/master
[workspace] $ git whatchanged --no-abbrev -M --pretty=raw xxxx..xxxx

The magic happens in git checkout -f xxxx which basically forces the repo to the "clean" state.

build environment: remove RUBYOPT

Still having some issue with bigtuna 0.1.4 and the build environment. In my case, RUBYOPT was set to: "-I/srv/dep/.rvm/gems/ruby-1.9.2-p180/gems/bundler-1.0.12/lib -rbundler/setup", which then causes the initial "bundler install" command to fail with: "Could not find activesupport-3.0.6 in any of the sources" or similar.

RVM on BigTuna

How do you get RVM to run under BigTuna env?

Unclear how to contribute to documentation

I've noticed a lot of lacking information in the documentation that I had to figure out from the source code. I'd like to update the docs to reflect things I learned, but can't figure out how to do that. Is there a repo somewhere?

Builds are created with 0777 permissions

Is there a good reason for this? I'm running on an Ubuntu Lucid 2.6.32-309-ec2 with Passenger. I have problems with this because bundler throws up red flags when the bundle folder inherits the 0777 permissions.

Besides that if there is no very good reason for this, just in the context of security maybe it should be addressed.

Let the user choose the notifications he wants

if I want XMPP notifications for example, I will receive a notification for build_failed, build_still_fails and build_fixed because that notifier was designed this way. But what if I also need a notification for build_passed? Or maybe I only want to receive a notification for build_failed.

I think it would be better if all 5 hooks would be defined in each notifier and that the user choose the ones he needs in the configuration form.

Missing navigation buttons

It is missing:

• Back to project on Project edit view (on the sidebar)
• Build now on Project edit view
• Back to project on Build view (it's all builds now)
• Edit project on Build view

Delayed::DeserializationError

I get the following error when I try to build a project after deleting failed or hung builds. Not exactly sure what's happening here, but it seems like something is getting corrupted in DelayedJob. It would be nice to have some sort of "big red button" clear the job queue feature.

Delayed::DeserializationError (Delayed::DeserializationError):
  app/models/project.rb:142:in `remove_project_jobs_in_queue'
  app/models/project.rb:141:in `each'
  app/models/project.rb:141:in `remove_project_jobs_in_queue'
  app/models/project.rb:45:in `build!'
  app/models/project.rb:42:in `build!'
  app/controllers/projects_controller.rb:22:in `build'

Pages redesign/restyle.

BigTuna seriously needs a better look. If you can spend some time on designing, go ahead and fork the project!

Private key support (for git)

While workarounds exist to get private keys to work for authenticating with git (using GIT_SSH env variable and a shell script), building support for this into BigTuna would make it much easier for people to use BigTuna with git. It will also enable people to use BigTuna on environments where they don't control the environment as readily, like Heroku.

[This is a new feature I am already working on, adding it here for visibility.]

Project with VSC only (no steps) should build properly

For now the project is in the 'now building' state. Delayed job finishes it but the status doesn't get updated -- orange colour remains.

Duplicate a project

Project/edit view should have an option to duplicate a project, so that you can easily set up a new project with e.g. only the branch changed and not need to rewrite each and every part of the configuration.

Heroku environment variables

Trying to use BigTuna for CI of a RailsApp on Heroku. Made it work using GIT_SSH workaround, but now am stuck on a the first step: "bundle install" inside the build script.

Fetching source index for http://rubygems.org/

sudo: must be setuid root
sudo: must be setuid root
/usr/ruby1.9.2/lib/ruby/1.9.1/rubygems/format.rb:38:in from_file_by_path': Cannot load gem at [/usr/ruby1.9.2/lib/ruby/gems/1.9.1/cache/rake-0.8.7.gem] in /app/tmp/flagship/build_3_20110415165235 (Gem::Exception) from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/source.rb:72:infetch'
from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/installer.rb:45:in block in run' from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:inblock in each'
from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in each' from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:ineach'
from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in run' from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/installer.rb:8:ininstall'
from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in install' from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:inrun'
from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in invoke_task' from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:indispatch'
from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in start' from /usr/ruby1.9.2/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/bin/bundle:13:in<top (required)>'
from /usr/ruby1.9.2/bin/bundle:19:in load' from /usr/ruby1.9.2/bin/bundle:19:in

'

I am sure that can be fixed with proper settings of environment variables, but not sure where to start. Very much appreciate any help.

BigTuna rocks!

Delayed jobs needs to be properly configured in order build jobs to execute

Hey! Builds won't execute unless you rake jobs:work. This is something mentioned nowhere! Maybe it should be noted in the documentation?

Using rvm to run configurations under different versions of ruby

Hi, I can't figure out how to use rvm with BigTuna to run configurations with different versions of ruby. I've tried adding the following to the start of my configuration build scripts:

rvm use 1.9.2-p0

But my gems and my app seems to run under 1.8.7 which I'm running BigTuna on.

I'm currently using version 0.1.2 of BigTuna.

Thanks,

Michael.

subprojects/stages/jobs

Did you think about creating some kind of "subprojects/stages/jobs", however you call it. To support different stages/branches of the same projects instead of creating separate projects?

Split project and build configurations

Right now, each project can only have one build configuration. If you want to run several projects and/or branches with several configurations (e.g. using RVM), you have to create a project for each configuration.
This is tedious and you'll pretty soon loose track of your projects' status if you have lots of projects or configurations.

This is the current version: http://yfrog.com/3ubigtuna1p

And this is how I imagine configuration support: http://yfrog.com/5fbigtuna2p

Flush stdout/err to build status page periodically

As a step in a build runs, could the output buffer from that flush to the database as it occurs? It would be cool to watch progress in the browser interactively.

It could flush at some reasonable rate, like every 10-15 seconds?

BigTuna is not missing constant VCS

I have configured the following steps:

Here are my available configurations: http://grab.by/870t
This is the status info I get from the front-end: http://grab.by/870s
I have configured the vcs: http://grab.by/870x

The build is not running so I started looking at the bigtuna logs and found the following:

2010-12-29T06:56:45-0800: [Worker(delayed_job host:ip-10-102-75-206 pid:3833)] Starting job worker
2010-12-29T06:58:03-0800: [Worker(delayed_job host:ip-10-102-75-206 pid:3833)] Build #4 @ December 29, 2010 14:57 failed with ArgumentError: BigTuna is not missing constant VCS! - 0 failed attempts
2010-12-29T06:58:03-0800: [Worker(delayed_job host:ip-10-102-75-206 pid:3833)] PERMANENTLY removing Build #4 @ December 29, 2010 14:57 because of 1 consecutive failures.
2010-12-29T06:58:03-0800: [Worker(delayed_job host:ip-10-102-75-206 pid:3833)] 1 jobs processed at 0.3422 j/s, 1 failed ...

That is in log/delayed_jobs.log

Thank you

When queuing builds, take the last commit received

If I push to master on GitHub, it kicks off a build on BigTuna. This build takes about 18 minutes on my CI box.

Say I commit and push two more times in that 18 minutes. This queues up two more commits to be tested with BigTuna.

Currently, BigTuna will run the 18 minute build twice, once per commit. I think instead, it should only kick off a build for the most recent commit seen to date.

cd-ing in one build step and running bundle install bundle's bigtuna's Gemfile

In the output below, despite the fact that I'm cd-ing into the %build_dir%, bundle install is bundling bigtuna's Gemfile, not the app located in the build dir. What is going on here?

Build steps:

cd %build_dir%
bundle install
cp examples/config/* config/
bundle exec rake --trace

Output:

cd /var/www/bigtuna/releases/20110223023156/builds/data_wrangler/build_22_20110223104026

bundle install
Using rake (0.8.7) 
Using abstract (1.0.0) 
Using activesupport (3.0.3) 
Using builder (2.1.2) 
Using i18n (0.4.2) 
Using activemodel (3.0.3) 
Using erubis (2.6.6) 
Using rack (1.2.1) 
Using rack-mount (0.6.13) 
Using rack-test (0.5.6) 
Using tzinfo (0.3.23) 
Using actionpack (3.0.3) 
Using mime-types (1.16) 
Using polyglot (0.3.1) 
Using treetop (1.4.9) 
Using mail (2.2.10) 
Using actionmailer (3.0.3) 
Using arel (2.0.4) 
Using activerecord (3.0.3) 
Using activeresource (3.0.3) 
Using addressable (2.2.2) 
Using crack (0.1.8) 
Using daemons (1.1.0) 
Using delayed_job (2.1.1) 
Using eventmachine (0.12.10) 
Using multipart-post (1.0.1) 
Using faraday (0.5.3) 
Using haml (3.0.24) 
Using httparty (0.4.5) 
Using bundler (1.0.2) 
Using thor (0.14.6) 
Using railties (3.0.3) 
Using rails (3.0.3) 
Using jquery-rails (0.2.6) 
Using json (1.4.6) 
Using notifo (0.1.0) 
Using open4 (1.0.1) 
Using roauth (0.0.3) 
Using xmpp4r (0.5) 
Using scashin133-xmpp4r-simple (0.8.9) 
Using shout-bot (0.0.4) 
Using sqlite3-ruby (1.3.1) 
Using stringex (1.2.0) 
Using twitter-stream (0.1.10) 
Using tinder (1.4.3) 
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

Your bundle was installed to `/var/www/bigtuna/shared/bundle`

cp examples/config/* config/

bundle exec rake --trace

Exit code: 1
(in /var/www/bigtuna/shared/builds/data_wrangler/build_22_20110223104026)
rake aborted!
no such file to load -- sinatra
/var/www/bigtuna/shared/builds/data_wrangler/build_22_20110223104026/lib/web_api.rb:1:in `require'
/var/www/bigtuna/shared/builds/data_wrangler/build_22_20110223104026/lib/web_api.rb:1
./lib/initializer.rb:26:in `require'
./lib/initializer.rb:26
/var/www/bigtuna/shared/builds/data_wrangler/build_22_20110223104026/Rakefile:4:in `require'
/var/www/bigtuna/shared/builds/data_wrangler/build_22_20110223104026/Rakefile:4
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/var/www/bigtuna/shared/bundle/ruby/1.8/gems/rake-0.8.7/bin/rake:31
/var/www/bigtuna/shared/bundle/ruby/1.8/bin/rake:19:in `load'
/var/www/bigtuna/shared/bundle/ruby/1.8/bin/rake:19

Make it working on Heroku

Very few CI ruby applications work on Heroku. That's bad...

autotest : superclass mismatch for class StepListTest

When running autotest, you get the following error:

./test/integration/step_list_test.rb:3: superclass mismatch for class StepListTest (TypeError)

...because StepListTest is defined twice with different superclasses in test/integration/step_list_test.rb & test/unit/step_list_test.rb

ENV cleanup strategy

Can you explain me why bigtuna cleans up the ENV after every step instead of every "part" or build?

It's a hell having to prefix with rvm exec RAILS_ENV, DISPLAY, etc.. for every step you need to execute...

tmp folder is missing from git repository.

When starting delayed_job, it's failed because tmp dir is missing.
Cab you add it with a .gitempty file.
Thanks!

Question: On deploying to EY AppCloud

What's the proper way to deploy BigTuna on EY's AppCloud service?

Update docs

Update documentation on https://github.com/appelier/bigtuna-webpage to reflect all the newest changes in 0.1.4

Automatic BUNDLE_GEMFILE setup for bundled projects

Issue #44 resolves problem of repeating some step parts, one can use it for setting BUNDLE_GEMFILE env.
It would be nice if people wouldn't have to set up this env,maybe we can check for Gemfile existence in the project and try to set the env appropriately.

bundler install picks up wrong Gemfile

Since updating to 0.1.3, all builds fail because running "bundle install --path=%project_dir%/bundle --deployment" now somehow picks up bigtuna's Gemfile instead of the project's Gemfile. As a result, the project is missing the .bundle directory.

As a workaround for that I'm using: "bundle install --gemfile=%build_dir%/Gemfile --path=%project_dir%/bundle --deployment"

Do a pull instead of clone?

Would it be possible to configure BigTuna to do a pull instead of a clone for each build run?

Bunlder uses the BigTuna Gemfile and not the project's one

I'm monitoring a few applications which depend on Bundler in my fresh BigTuna installation (thanks for that). Installing the necessary gems works fine but running a bundle exec command in a subsequent step uses the BigTuna Gemfile, not the project one.

I found a workaround by specifying the BUNDLE_GEMFILE before each step but it seems a bit of an overkill.

Am I missing something or can we just add the environment variable in the code somewhere to have it executed before each step to make sure BigTuna uses the correct Gemfile?

Here is a full example:

bundle install --gemfile=%build_dir%/Gemfile --path=%project_dir%/bundle --deployment
cp %project_dir%/database.yml.example %build_dir%/config/database.yml
export BUNDLE_GEMFILE=%build_dir%/Gemfile; RAILS_ENV=test bundle exec rake db:setup
export BUNDLE_GEMFILE=%build_dir%/Gemfile; RAILS_ENV=test bundle exec rake

Thanks!

ENV cleanup

Why do we dupe ENV, set RAILS_ENV to test and revert back to previous ENV? There are some steps I do not necessarily want to execute into test ENV. Maybe we should make this behaivour parametrizable?

Bigtuna cannot find RVM

Hope that someone can help me here. I'm trying to setup bigtuna with RVM and I'm having problems.

My very first build step looks like the following:
rvm 1.9.2-head@rails3 && bundle install --path=/home/me/apps/myapp/releases/20110126170734/builds/myapp/bundle --deployment

and it fails with:

sh: rvm: command not found

If I open a session on my server and type rvm, it works perfectly. Any idea?

Thanks!

configure.html.haml

Not sure why this should always be a text_area_tag. Seems like it might be easier to include a template to use for each hook. Inside something like extras/big_tuna/hooks/mailer/configure.html.haml and load that.

Git doesn't support --branch in 'clone' command prior to 1.6.5

We have to make the Git vcs handler work even if git is < 1.6.5

Multiple commits build

With decentralized vcs, you can push on the "central repo" multiple commits at the same times. In big tuna you will see a build only for the last commit.

It would be great to see on the details of the build, all the commits which have trigged that build.

Keep new builds in same clone directory

I noticed that bigtuna creates a new directory for each build, and a fresh clone at that. Is there a reason it doesn't just pull in the lastest changes for whatever branch it's on, via git pull? Having different directories forces you to automate things like copying config files over and the like for every build, which is not the worst thing in the world, but seems unnecessary. Thanks.

CCMenu/CCTray support - XmlStatusReport generation

Hi,

i've added support for CCMenu (http://ccmenu.sourceforge.net/) by generating an XmlStatusReport.aspx. Most of the
code was "borrowed" from cruisecontrol.rb - so the XML generated should be ok.

gorenje@63f3d11

There aren't any tests yet (hence no pull request) but it does work with my CCMenu.

As an aside, I am getting a failing test on master and my branch:

  1) Failure:
test_project_with_invalid_repo_shows_appropriate_errors(ProjectsTest) [/test/integration/projects_test.rb:113]:
<false> is not true.

didn't have time to look into it...

Project site has private repository URL

On the home page: http://bigtuna.appelier.com/

git clone [email protected]:appelier/bigtuna.git
Cloning into bigtuna...
ERROR: Permission to appelier/bigtuna denied to jstotz.
fatal: The remote end hung up unexpectedly

Should be https://github.com/appelier/bigtuna.git

MySQL: Text field for output too short

Hi,

the output fields on build_parts and builds are both text types, which means that when using MySQL* these are truncated to 64K characters. This might be fine for most things, but is insufficient if the output of bundle install and rake db:migrate are included and then a bunch of test outputs.

class OutputNeedsToBeLongtextWithMysql < ActiveRecord::Migration
  def self.up
    change_column :build_parts, :output, :longtext
    change_column :builds, :output, :longtext
  end

  def self.down
    change_column :build_parts, :output, :text
    change_column :builds, :output, :text
  end
end

the migration has no effect using sqlite but does change the column to longtext when using mysql. The commit is on a branch on my fork.

*=http://www.electrictoolbox.com/maximum-length-mysql-text-field-types/

Documentation for configuring built-in hooks such as Campfire, email, etc

It looks like big tuna ships with some built-in hooks (in the extras folder) but I can't find any documentation that explains how to configure them.