Shared ENV variables for project.

[michalbugno]

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.

[michalbugno]

The shared_env branch contains the solution. We thought of the best solution and we came with this:
Each configuration may contain any number of shared variables which simply get replaced, just like %build_dir% and %project_dir%. We thought of this because creating an ENV-specific solution would be much less flexible. This way we can set up any command-line we want and also won't be limited to ENV only. For example

%env% => env RAILS_ENV=test BUNDLE_GEMFILE=%build_dir%/Gemfile
%runner% => rvm 1.8.7 exec

We can do:

1. cp /config/files %build_dir%/config
2. %runner% %env% bundle install
3. %runner% %env% bundle exec rake db:migrate
4. %runner% %env% bundle exec rake test

Any thoughts?

[knoopx]

I would prefere to put this as a build part and forget about everything else...

export DISPLAY=:99.0
export RAILS_ENV=development
rvm use --create 1.9.2@app

cd %build_dir%

bundle install
rake db:reset
rake spec
rake cucumber

I don't feel like "the build script" should be hosted within the app code VCS and when/or if the env should be cleaned up. It's up to you, to your build process needs. This was one of the reasons I started using bigtuna instead of hudson or any other ruby/rails-centric CI's.

[michalbugno]

The build part tries to be as much agnostic as it can be. It's just a list of command shells. The thing here is that the commands do not know anything even about each other. They are simply processes spawn from the bigtuna's main process, line by line. This way you get stdout/stderr split up, and also your build process stops if any of the commands fails.

Sure, we can store the shell script in some executable file (like /build_dir/build.sh) and the just run it within shell, but this leaves us with no error handling (what if some command fails?) and doesn't distinguish build 'parts' (like migration, then tests, then something). You can address this by doing command1 && command2 && command3 but this gets just ugly, doesn't it?

[michalbugno]

And also just to be clear, it has always been this way in BigTuna :-) We are always happy to discuss solutions though, maybe we can figure out something that pleases both sides.

When coding this solution we thought mainly about leaving as much space for many scenarios user's can build their apps, and also leave the BigTuna features like non-zero exit code breaks the build, and separate outputs of commands.

[knoopx]

aren't build parts executed in parallel?

[michalbugno]

Build parts meaning build configurations? Nope, they are executed in order (of creation, AFAIR).