thoughtworks / cruisecontrol.rb Goto Github PK
View Code? Open in Web Editor NEWCruiseControl for Ruby. Keep it simple.
Home Page: http://cruisecontrolrb.thoughtworks.com
License: Apache License 2.0
CruiseControl for Ruby. Keep it simple.
Home Page: http://cruisecontrolrb.thoughtworks.com
License: Apache License 2.0
Steps to reproduce:
OR
One of the most valuable features of CruiseControl is the ability to get a snapshot of a build. If only some errors are visible sometimes, we lose some of the core value.
It needs to be re-recorded as a general part of the 2.0 deliverable.
CRUISE_DATA_ROOT used to be located in the global namespace and has been moved to CruiseControl::Application::CRUISE_DATA_ROOT. I'm generally for replacing these kinds of global constants with their namespaced equivalents, but we can't break existing site_config settings without a deprecation warning. To fix:
Reported by @alexeyv.
If you have a subversion repository using the new svn externals (such as relative URLs), cc.rb says error when it tries to check the working copy to see if it's up to date.
For example, this is fine:
external_path svn://rubyforge.org/var/svn/cruisecontrolrb/trunk/daemon
but this will break cc.rb:
^/passing_project caret_external
The arguments in the new format have been reversed, and cc.rb doesn't know how to handle it. Also, building the svn URL for the external is no longer straightforward. cc.rb would have to handle relative URLs and URLs rooted at the repository (such as the example above).
The documentation needs to be revised. Specifically:
When I start CC using ./cruise start --daemon, my builder will run for the very first time. But after that I immediately got "Source Control Error" which suggest that it cannot git fetch origin, but when I do the command line inside, it can :(
[error] /Users/administrator/.cruise/projects/cp/work administrator$ git fetch origin
You don't exist, go away!
fatal: The remote end hung up unexpectedly
When I cd into the "work" directory and do a normal git fetch origin, I am not getting fatal error. However, trying to ./cruise stop (I am not sure if there is such thing) will make CC working again, but only for a while.
Previously my CC is all working fine.
In site_config.rb I set:
Configuration.dashboard_refresh_interval = 90.seconds
This is because our log files are kinda large and we can have many people looking at the build. When I'm looking at the build in progress it will always auto-refresh every 5 seconds even though. I realize the distinction between project & build but with the auto-refresh I can't scroll down or check out current failures without the page resetting.
I get that error when running:
./cruise add owl -r -s git
from the master branch of cruisecontrol.rb
I get that error when running:
./cruise add owl -r repo -s git
from the master branch of cruisecontrol.rb
Though official documentation says, CC works with 1.8.6 only but seems people are using it with higher versions also. But does it work with 1.9.2. I tried to use it but it gave following error:
cruise data root = '/Users/me/.cruise'
FAILED: undefined method `active_support' for #<CruiseControl::Application:0x1bdb54>
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/application.rb:77:in `method_missing'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/config/environments/add_project.rb:2:in `block in <top (required)>'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/application.rb:47:in `class_eval'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/application.rb:47:in `configure'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/config/environments/add_project.rb:1:in `<top (required)>'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `block in require'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `block in load_dependency'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/application/bootstrap.rb:11:in `block in <module:Bootstrap>'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/initializable.rb:25:in `instance_exec'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/initializable.rb:25:in `run'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/initializable.rb:50:in `block in run_initializers'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/initializable.rb:49:in `each'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/initializable.rb:49:in `run_initializers'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/application.rb:134:in `initialize!'
/Users/me/.rvm/gems/ruby-1.9.2-p180/gems/railties-3.0.7/lib/rails/application.rb:77:in `method_missing'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/config/environment.rb:5:in `<top (required)>'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/script/add_project:69:in `require'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/script/add_project:69:in `<top (required)>'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/lib/cruise_control/init.rb:61:in `load'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/lib/cruise_control/init.rb:61:in `add'
/Users/me/apps/thoughtworks-cruisecontrol.rb-v1.4.0-161-ga870485/thoughtworks-cruisecontrol.rb-a870485/lib/cruise_control/init.rb:12:in `run'
./cruise:7:in `<main>'
need to monkey patch rails (fixed in 2.3.6)
module ActionMailer
class Base
private
def perform_delivery_smtp(mail)
destinations = mail.destinations
mail.ready_to_send
sender = (mail['return-path'] && mail['return-path'].spec) || mail['from']
smtp = Net::SMTP.new(smtp_settings[:address], smtp_settings[:port])
smtp.enable_starttls_auto if smtp_settings[:enable_starttls_auto] && smtp.respond_to?(:enable_starttls_auto)
smtp.start(smtp_settings[:domain], smtp_settings[:user_name], smtp_settings[:password],
smtp_settings[:authentication]) do |smtp|
smtp.sendmail(mail.encoded, sender, destinations)
end
end
end
end
Either get the documentation statically generated so we can place it there or put a redirect in place that points to cruisecontrolrb.thoughtworks.com.
Currently CC.rb doesn't integrate with RVM, in the sense that it has no way to automatically handle any .rvmrc files that might be checked into your project. You can handle them yourself with a custom build script, but the default build mechanism does nothing for you. If this is a feature that would be helpful, we should target it for a future release.
In order for build-via-Rake-command to make any sense at all, a modern CI server must check for the existence of a Gemfile and honor it if necessary by resolving dependencies to Bundler's satisfaction.
This is currently working in a limited sense and CC.rb will honor Gemfiles if they exist by bundle gems into the vendor path that's local to the project. But the bundle install command needs to be properly configurable in order to be useful, and the execution of it needs to be simpler (todo: switch to ruby -S bundle ... rather than trying to resolve the path to the Bundler binary by hand.)
As reported by @alexeyv:
Rails session (cookie based, of course) from the older Rails version makes the newer Rails version blow up thus:
ActionDispatch::Session::SessionRestoreError (Session contains objects whose class definition isn't available. Remember to require the classes for all objects kept in the session. (Original exception: uninitialized constant ActionController::Flash::FlashHash [NameError])): lib/cruise_control/init.rb:49:in
start'
lib/cruise_control/init.rb:46:in tap' lib/cruise_control/init.rb:46:in
start'
lib/cruise_control/init.rb:12:in send' lib/cruise_control/init.rb:12:in
run'`
Build Changeset in web interface looks like this:
[SourceControl::Git::Revision:(0a9cbe11581ec160af7ac152746fc3d006b49244)]
Here a patch to fix it.
diff --git a/app/models/project.rb b/app/models/project.rb index e1f86d4..8a1d15a 100644 --- a/app/models/project.rb +++ b/app/models/project.rb @@ -267,7 +267,7 @@ class Project begin if build_necessary?(reasons = []) remove_build_requested_flag_file if build_requested? - return build(source_control.latest_revision, reasons) + return build(source_control.latest_revision, reasons.flatten) else return nil end
You should be able to install CC.rb in gem form via Rubygems. Such a gem should expose the cruise executable as an entry point into the app, and should be daemonizable on that basis as well. It should work on Windows, Linux, and Mac.
It would be super nice to replace BASH colors to <span style="color:#…">…</span>
when displaying the build.log
CC.rb should function correctly on Ruby 1.9 and Rails 3 on Windows, which is to say:
Its pretty bad when the solution demo is busted: http://cruisecontrolrb.thoughtworks.com/projects
If JUnit test results exist--for example, as generated by a tool like ci_reporter--we should recognize them and use them to render completion rates and build failures. Running the entire build log through BuildLogParser on every render of the build page isn't efficient and requires a great deal of ongoing maintenance.
A very big build log is sensibly truncated and not displayed in the dashboard. In such a circumstance, I should be able to just download the build.log on my local machine and inspect it for problems since not all the test/errors and failures are displayed in the dashboard for some reason.
This is already available in the latest builds. Added for tracking purposes.
In order to update certain elements of the UI in a more dynamic fashion, and in order to support third-party consumers beyond your standard CCTray consumers, it would be nice to provide a JSON representation of the project resource. I'm currently working on this in a local fork.
in public/cruisecontrol.less, line #383. it specify the color of the text to be cruise-blue.
.build_link {
a {
display: block;
padding: 6px 6px 6px 10px;
color: @cruise-blue;
border-right: 1px solid #bbb;
&:hover {
text-decoration: none;
background-color: lighten(#ccc, 10%);
}
}
I believe in the older versions, when a build failed, the sidebar text is red, which is what I want. I couldn't just use customized site.css to override it using failed class because this overrides a.failed. The only solution seems to get rid of this line.
Is there a reason you want it to be there? Thanks
it gave me something like this:
[SourceControl::Git::Revision:(bc2feba87882f81ad6f601ed72a7f241d3ac2c2f)]
instead of the files being changed, who changed etc.
the version is the current master.
Thanks
(There is a two-years-old ticket #270 with a proposed patch to fix it).
One would expect to be able to just set do_clean_checkout and be done; however this would result in the work directory disappearing and the web server refusing any page requests. There are workarounds, but the documentation doesn't mention any of them or even that this is an issue in the 1st place.
The project creation workflow through the UI (Add Project view etc.) requires validation as it's currently possible to rm -rf the ~/.cruise/projects directory by adding a blank project.
To reproduce:
1 - Add Project view
2 - Click create
Params should look like:
"project"=>{"name"=>"",
"source_control"=>{"repository"=>"",
"source_control"=>"Git"}}}
SourceControl.create checks for nil instead of blank, so no exception is raised.
raise ArgumentError, "options should include repository" unless scm_options[:repository]
Project.create catches an exception trying to checkout a local copy, given there's no project name it rm -rf the project directory in the rescue.
```FileUtils.rm_rf "#{dir}/#{project.name}"````
http://cruisecontrolrb.thoughtworks.com/builds/CruiseControlRB
And has been since April 27th, almost a month.
As a CI user, I'd like to be able to copy and paste a URL into CCMenu/CCTray so I can monitor builds from my desktop.
Requested by @alexeyv.
The changelog needs to be updated in preparation for 2.0. I'll push in some of the major changes until this point.
Keeping this one open so that any new noteworthy changes that happen should be updated in the changelog file as the change is being made.
http://cruisecontrolrb.thoughtworks.com/documentation/manual#handling_custom_build_artifacts
wrong constnt name CC_BUILD_ARTFACTS. it should be CC_BUILD_ARTIFACTS
CC.rb should be daemonizable under Unix-like environments under Ruby 1.9 and Rails 3, which is to say:
I don't get it - the latest version in the downloads tab hasn't been updated since 2009.
How are we supposed to a more recent version short of doing a git clone?
In order to create a clean break with past releases, the UI should be revamped slightly. I'm not proposing a complete redesign, but what elements exist already should be tweaked to provide maximal information content in less space than they occupy now, and more and better information should be made available on the build page. I'm currently working on this and plan to post screenshots here or on the developers mailing list for review.
This is already complete in the sense that all tests pass and the application can perform builds correctly, but certain use cases (daemonization and cross-platform compatibility) need additional testing.
On cloning the repo bundle install fails when I run it with bundler version 1.0.15:
(bundler-problem)$ rvm gemset create cc
'cc' gemset created (/Users/jon/.rvm/gems/ruby-1.8.7-p352@cc).
(bundler-problem)$ rvm use @cc
Using /Users/jon/.rvm/gems/ruby-1.8.7-p352 with gemset cc
(bundler-problem)$ gem install bundler
Fetching: bundler-1.0.15.gem (100%)
Successfully installed bundler-1.0.15
1 gem installed
(bundler-problem)$ bundle install
Fetching source index for http://rubygems.org/
Bundler could not find gem "bundler" (1.0.15)
Right now, CC.rb has no way, either visually or in the config, to break a project's build into multiple stages. Multiple builds that share the same SCM are separated using an "if"-switch in the project config, and although one "project" can depend on another, there's no visual indication of those relationships.
In order to build anything even remotely resembling a proper build pipeline, it would help if there was a nice way to both show and define this information. CC.rb becomes difficult to manage once you've defined a lot of separate projects.
In short, the check_auth_args method has changed arity and the monkey patch is still using the old arity (three args instead of two). Ruby 1.8.7 uses two separate methods, check_auth_method and check_auth_args, to accomplish the same thing.
The following patch illustrates the problem and the solution:
diff -rau cruisecontrol.rb/lib/smtp_tls.rb current/lib/smtp_tls.rb
--- cruisecontrol.rb/lib/smtp_tls.rb 2010-01-08 17:45:34.000000000 -0800
+++ current/lib/smtp_tls.rb 2010-01-08 17:27:25.000000000 -0800
@@ -4,7 +4,10 @@
private
def do_start(helodomain, user, secret, authtype)
raise IOError, 'SMTP session already started' if @started
- check_auth_args user, secret, authtype if user or secret
+ if user or secret
+ check_auth_method(authtype || DEFAULT_AUTH_TYPE)
+ check_auth_args user, secret
+ end
open_conversation(helodomain)
...and pass it on to builder. at the moment there's $VERBOSE_MODE, but it doesn't get set from a command line flag.
There are several related issues:
daemon/daemon_helper.rb
requires mongrel to be installed system wide, but then it starts server, which uses Bundler, and there is no mongrel in Gemfile. So Webrick is always being used.mongrel_rails
is not able to stop Webrick server for some reason.To fix the issue, it's necessary to do following:
daemon_helper.rb
, and do not require mongrel from this file. It will improve startup time, and fix unnecessary requirement on system-wide mongrel gem.Gemfile
, so CruiseControl::Init
will use it.This will fix things in Ruby 1.8, but I have no idea how other versions of Ruby will behave.
I'm getting invalid byte sequence in US-ASCII which is a sign for missing magic encoding comment in some source file. unfortunateley i can't see the stack trace to i dont know which file it is.
There should be a line
# -- encoding : utf-8 --
as the first line in every source file as a requirement for ruby-1.9.
Thanks,
Paul
Rails 3 uses the mysql2 adapter, should add that to the list in addition to mysql.
Currently, the code is (inside script/builder
):
CRUISE_OPTIONS[:log_file_name] = "log/#{CRUISE_OPTIONS[:project_name]}_builder.log"
It should get changed to place the log file in the Cruise home directory (by default, ~/.cruise).
db:migrate should only be used by developers, it is not meant to be used as a means to load a database. db:schema:load should be used instead. Perhaps also db:seed to seed data.
CC.rb should function correctly on Ruby 1.9 and Rails 3 on Windows, which is to say:
The builder concept is an implementation detail that unfortunately leaks through to the UI. Certain experienced users have requested the ability to kill builders via a button, because they go awry from time to time. Better, IMO, would be to improve builder management to the point where CC.rb detects and kills bad ones itself, but in the meantime we should add the ability to kill builders via a build button. Such a button should function correctly across all platforms (JRuby, Windows, Un*x) if possible.
I am not really sure if this is an issue with cruisecontrol.rb, but anyhow I need help...
I am running cruise with passenger for the webfrontend and github as coderepository... the builder in general seems to work and individual builds start and run until the end of the migrations.... then I get the error: Couldn't get a file descriptor referring to the console without any additional information.
Of course the build should continue after the migrations and run all the tests...
Does anybody know what the problem could be?
I am using
ruby 1.9.2p180
thoughtworks-cruisecontrol.rb-v1.4.0-183-geaba789.tar
passenger 3.0.7
Ubuntu 10.04.3 LTS
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.