Beginning with Cerberus / Re-running broken build with no extra commit / Post-scm config updates
22 views
Skip to first unread message
Matthew Krom
Dec 5, 2009, 11:54:33 PM12/5/09
to Cerberus
Hi all,
After having some problems installing "other" CI solutions, tonight I
am trying Cerberus, with decent results. However...
1) It appears that if a build fails, it will never be attempted again
until there is a new code commit? (This is from one single
experience, but it appears that is what happened.) Is there a way to
"force" a rebuild other than making a bogus commit? Maybe I missed
something here. (There are a lot of reasons a build could fail that
are not fixed with a source code commit.)
2) How do I tell Cerberus to make a configuration update after the SCM
checkout? For instance, since database.yml is not checked in, we need
to rename database.yml.ci to database.yml before running the CI specs.
3) Is there a way to view feedback ('verbose mode'?) on what Cerberus
is doing? In case #1 above, I was stumped for awhile--just looked
like Cerberus was failing without explaining why. It could be useful
for Cerberus to say "considering project_name.... no updates.... not
building". (Once I've found my way around the project, I could
contribute those updates.)
Thanks for answers and insights! Looking forward to adding projects
2, 3, and up to 6 or 8 onto Cerberus once I get the hang of it.
Matt
After having some problems installing "other" CI solutions, tonight I
am trying Cerberus, with decent results. However...
1) It appears that if a build fails, it will never be attempted again
until there is a new code commit? (This is from one single
experience, but it appears that is what happened.) Is there a way to
"force" a rebuild other than making a bogus commit? Maybe I missed
something here. (There are a lot of reasons a build could fail that
are not fixed with a source code commit.)
2) How do I tell Cerberus to make a configuration update after the SCM
checkout? For instance, since database.yml is not checked in, we need
to rename database.yml.ci to database.yml before running the CI specs.
3) Is there a way to view feedback ('verbose mode'?) on what Cerberus
is doing? In case #1 above, I was stumped for awhile--just looked
like Cerberus was failing without explaining why. It could be useful
for Cerberus to say "considering project_name.... no updates.... not
building". (Once I've found my way around the project, I could
contribute those updates.)
Thanks for answers and insights! Looking forward to adding projects
2, 3, and up to 6 or 8 onto Cerberus once I get the hang of it.
Matt
Peter Fitzgibbons
Dec 7, 2009, 11:00:40 AM12/7/09
to cerbe...@googlegroups.com
HI Mattew,
Peter Fitzgibbons
(847) 687-7646
Email: peter.fi...@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fi...@gmail.com
Welcome to the community!!
On Sat, Dec 5, 2009 at 10:54 PM, Matthew Krom <matthe...@gmail.com> wrote:
Hi all,
After having some problems installing "other" CI solutions, tonight I
am trying Cerberus, with decent results. However...
1) It appears that if a build fails, it will never be attempted again
until there is a new code commit? (This is from one single
experience, but it appears that is what happened.) Is there a way to
"force" a rebuild other than making a bogus commit? Maybe I missed
something here. (There are a lot of reasons a build could fail that
are not fixed with a source code commit.)
$ cerberus build myapp --force
You can find this in the source at ./lib/cerberus/builder/cli.rb:44
2) How do I tell Cerberus to make a configuration update after the SCM
checkout? For instance, since database.yml is not checked in, we need
to rename database.yml.ci to database.yml before running the CI specs.
Hmm... not so sure on this one. I've found that the one-time setup of database.yml
is just a necessity. Other thoughts, community?
3) Is there a way to view feedback ('verbose mode'?) on what Cerberus
is doing? In case #1 above, I was stumped for awhile--just looked
like Cerberus was failing without explaining why. It could be useful
for Cerberus to say "considering project_name.... no updates.... not
building". (Once I've found my way around the project, I could
contribute those updates.)
Good idea for a patch!
Thanks for answers and insights! Looking forward to adding projects
2, 3, and up to 6 or 8 onto Cerberus once I get the hang of it.
Matt
--
You received this message because you are subscribed to the Google Groups "Cerberus" group.
To post to this group, send email to cerbe...@googlegroups.com.
To unsubscribe from this group, send email to cerberusci+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cerberusci?hl=en.
Peter Fitzgibbons
(847) 687-7646
Email: peter.fi...@gmail.com
IM GTalk: peter.fitzgibbons
IM AOL: peter.fi...@gmail.com
Craig Jolicoeur
Dec 7, 2009, 11:01:22 AM12/7/09
to cerbe...@googlegroups.com
Hi Matt,
Glad you found Cerberus.
Regarding your questions. First, you can force a rebuild by passing
the "--force" parameter to the cerberus command. As you've found out,
Cerberus doesn't rebuild by default unless it notices changes in the
SCM, but you can manually force a new run with the --force param.
Right now there is not a way to specify any kind of "pre-hook"
configuration changes, but you do have a few options. First, if your
SCM supports it (I think both git and subversion do) you can run an
SCM hook on a post-checkout and write a script to do what you need
configuration-wise. Also, you could use the Cerberus "ruby builder"
and write a ruby script that does your configuration updates and then
kicks off your build process.
Lastly, there is a "--verbose" parameter that will give more detailed
output. Unfortunately, I don't think it currently works the same
under all SCM and Builder/Publisher types so its currently on the TODO
list as something that needs to be looked at. In your ~/.cerberus
directory you can look at the error.log, and under each project you
can check the build logs " ~/.cerberus/work/PROJECT_NAME/logs"
Development on cerberus has been slow as of late as I've been working
on a few other projects, but I hope to pick up some of the TODO list
soon.
- Craig
Glad you found Cerberus.
Regarding your questions. First, you can force a rebuild by passing
the "--force" parameter to the cerberus command. As you've found out,
Cerberus doesn't rebuild by default unless it notices changes in the
SCM, but you can manually force a new run with the --force param.
Right now there is not a way to specify any kind of "pre-hook"
configuration changes, but you do have a few options. First, if your
SCM supports it (I think both git and subversion do) you can run an
SCM hook on a post-checkout and write a script to do what you need
configuration-wise. Also, you could use the Cerberus "ruby builder"
and write a ruby script that does your configuration updates and then
kicks off your build process.
Lastly, there is a "--verbose" parameter that will give more detailed
output. Unfortunately, I don't think it currently works the same
under all SCM and Builder/Publisher types so its currently on the TODO
list as something that needs to be looked at. In your ~/.cerberus
directory you can look at the error.log, and under each project you
can check the build logs " ~/.cerberus/work/PROJECT_NAME/logs"
Development on cerberus has been slow as of late as I've been working
on a few other projects, but I hope to pick up some of the TODO list
soon.
- Craig
Niklas Koponen
Dec 7, 2009, 1:35:19 PM12/7/09
to cerbe...@googlegroups.com
>
> Development on cerberus has been slow as of late as I've been working
> on a few other projects, but I hope to pick up some of the TODO list
> soon.
>
In my case I have to say that cerberus has worked so well that there
> Development on cerberus has been slow as of late as I've been working
> on a few other projects, but I hope to pick up some of the TODO list
> soon.
>
is nothing I miss from the tool. It just works.
-Niklas
Craig Jolicoeur
Dec 7, 2009, 1:46:00 PM12/7/09
to cerbe...@googlegroups.com
Thanks Niklas,
Good to hear. It works well for my needs as well and I use it on all
my projects (30+ at this point), and I don't generally get much bug
reports or feedback from users.
I don't know if this means we don't have many users or there arent
many bugs. My guess is the former.
Still, there are some things that can be cleaned up and new features
like support for Ruby 1.9, etc..., but I'm glad to hear that it has
been working solidly for you.
- Craig
Good to hear. It works well for my needs as well and I use it on all
my projects (30+ at this point), and I don't generally get much bug
reports or feedback from users.
I don't know if this means we don't have many users or there arent
many bugs. My guess is the former.
Still, there are some things that can be cleaned up and new features
like support for Ruby 1.9, etc..., but I'm glad to hear that it has
been working solidly for you.
- Craig
Matthew Krom
Dec 8, 2009, 1:53:40 PM12/8/09
to cerberusci
Thanks, Peter and Craig. So far so good. I'm about ready for 'heavy-duty' use (meaning, relying on it to catch build breaks for several projects).
Another question (haven't looked at the source yet): Is there an exclusive lock in cerberus to prevent it from running twice concurrently? i.e., if we schedule cerberus in cron every 15 minutes, is there a chance it'll try to run the same test suite twice?
I'm not saying that some of the test suites take 15 minutes. But if we run cerberus with --force 4x/day, and then run it in "normal" mode every 10 minutes, if there are a lot of projects there could be plenty of collisions.
Thanks again for any insight!
Matt--
matthe...@gmail.com
MW Krom LLC
Cambridge, MA
Another question (haven't looked at the source yet): Is there an exclusive lock in cerberus to prevent it from running twice concurrently? i.e., if we schedule cerberus in cron every 15 minutes, is there a chance it'll try to run the same test suite twice?
I'm not saying that some of the test suites take 15 minutes. But if we run cerberus with --force 4x/day, and then run it in "normal" mode every 10 minutes, if there are a lot of projects there could be plenty of collisions.
Thanks again for any insight!
Matt
matthe...@gmail.com
MW Krom LLC
Cambridge, MA
Craig Jolicoeur
Dec 8, 2009, 2:17:08 PM12/8/09
to cerbe...@googlegroups.com
Matt,
Yes, there is locking mechanism on a per project basis to prevent the
same test suite from being run multiple times concurrently.
- Craig
Yes, there is locking mechanism on a per project basis to prevent the
same test suite from being run multiple times concurrently.
- Craig
somebox
Dec 8, 2009, 2:22:12 PM12/8/09
to Cerberus
I'm using Cerberus for running tests for several Rails projects on the
same server. I initially had some problems with them running over each
other, because of server load or whatever. This resulted in false
failure notifications that were fixed on the next run.
My solution in the end was to set up a script that does the following:
- check for the lock file, and exit if it exists
- touch a 'lock file'
- run each build in series (not using "build all", but by building
them one at a time)
- remove the lock file
Then this script gets called by cron every minute. If builds are still
being run, it skips and tries again next time.
So far this has been working pretty well for me :)
Jeremy
On Dec 8, 7:53 pm, Matthew Krom <matthew.k...@gmail.com> wrote:
> Thanks, Peter and Craig. So far so good. I'm about ready for 'heavy-duty'
> use (meaning, relying on it to catch build breaks for several projects).
>
> Another question (haven't looked at the source yet): Is there an exclusive
> lock in cerberus to prevent it from running twice concurrently? i.e., if we
> schedule cerberus in cron every 15 minutes, is there a chance it'll try to
> run the same test suite twice?
>
> I'm not saying that some of the test suites take 15 minutes. But if we run
> cerberus with --force 4x/day, and then run it in "normal" mode every 10
> minutes, if there are a lot of projects there could be plenty of collisions.
>
> Thanks again for any insight!
> Matt
>
> > cerberusci+...@googlegroups.com<cerberusci%2Bunsubscribe@googlegrou ps.com>
> > .
> > .
same server. I initially had some problems with them running over each
other, because of server load or whatever. This resulted in false
failure notifications that were fixed on the next run.
My solution in the end was to set up a script that does the following:
- check for the lock file, and exit if it exists
- touch a 'lock file'
- run each build in series (not using "build all", but by building
them one at a time)
- remove the lock file
Then this script gets called by cron every minute. If builds are still
being run, it skips and tries again next time.
So far this has been working pretty well for me :)
Jeremy
On Dec 8, 7:53 pm, Matthew Krom <matthew.k...@gmail.com> wrote:
> Thanks, Peter and Craig. So far so good. I'm about ready for 'heavy-duty'
> use (meaning, relying on it to catch build breaks for several projects).
>
> Another question (haven't looked at the source yet): Is there an exclusive
> lock in cerberus to prevent it from running twice concurrently? i.e., if we
> schedule cerberus in cron every 15 minutes, is there a chance it'll try to
> run the same test suite twice?
>
> I'm not saying that some of the test suites take 15 minutes. But if we run
> cerberus with --force 4x/day, and then run it in "normal" mode every 10
> minutes, if there are a lot of projects there could be plenty of collisions.
>
> Thanks again for any insight!
> Matt
>
> On Mon, Dec 7, 2009 at 11:01 AM, Craig Jolicoeur <cpjolico...@gmail.com>wrote:
>
>
>
>
>
> > Hi Matt,
>
> > Glad you found Cerberus.
>
> > Regarding your questions. First, you can force a rebuild by passing
> > the "--force" parameter to the cerberus command. As you've found out,
> > Cerberus doesn't rebuild by default unless it notices changes in the
> > SCM, but you can manually force a new run with the --force param.
>
> > Right now there is not a way to specify any kind of "pre-hook"
> > configuration changes, but you do have a few options. First, if your
> > SCM supports it (I think both git and subversion do) you can run an
> > SCM hook on a post-checkout and write a script to do what you need
> > configuration-wise. Also, you could use the Cerberus "ruby builder"
> > and write a ruby script that does your configuration updates and then
> > kicks off your build process.
>
> > Lastly, there is a "--verbose" parameter that will give more detailed
> > output. Unfortunately, I don't think it currently works the same
> > under all SCM and Builder/Publisher types so its currently on the TODO
> > list as something that needs to be looked at. In your ~/.cerberus
> > directory you can look at the error.log, and under each project you
> > can check the build logs " ~/.cerberus/work/PROJECT_NAME/logs"
>
> > Development on cerberus has been slow as of late as I've been working
> > on a few other projects, but I hope to pick up some of the TODO list
> > soon.
>
> > - Craig
>
> > On Sat, Dec 5, 2009 at 11:54 PM, Matthew Krom <matthew.k...@gmail.com>
>
>
>
>
>
> > Hi Matt,
>
> > Glad you found Cerberus.
>
> > Regarding your questions. First, you can force a rebuild by passing
> > the "--force" parameter to the cerberus command. As you've found out,
> > Cerberus doesn't rebuild by default unless it notices changes in the
> > SCM, but you can manually force a new run with the --force param.
>
> > Right now there is not a way to specify any kind of "pre-hook"
> > configuration changes, but you do have a few options. First, if your
> > SCM supports it (I think both git and subversion do) you can run an
> > SCM hook on a post-checkout and write a script to do what you need
> > configuration-wise. Also, you could use the Cerberus "ruby builder"
> > and write a ruby script that does your configuration updates and then
> > kicks off your build process.
>
> > Lastly, there is a "--verbose" parameter that will give more detailed
> > output. Unfortunately, I don't think it currently works the same
> > under all SCM and Builder/Publisher types so its currently on the TODO
> > list as something that needs to be looked at. In your ~/.cerberus
> > directory you can look at the error.log, and under each project you
> > can check the build logs " ~/.cerberus/work/PROJECT_NAME/logs"
>
> > Development on cerberus has been slow as of late as I've been working
> > on a few other projects, but I hope to pick up some of the TODO list
> > soon.
>
> > - Craig
>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/cerberusci?hl=en.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Cerberus" group.
> > To post to this group, send email to cerbe...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > cerberusci+...@googlegroups.com<cerberusci%2Bunsubscribe@googlegrou ps.com>
> >http://groups.google.com/group/cerberusci?hl=en.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Cerberus" group.
> > To post to this group, send email to cerbe...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/cerberusci?hl=en.
>
> --
> matthew.k...@gmail.com
> >http://groups.google.com/group/cerberusci?hl=en.
>
> --
Craig Jolicoeur
Dec 8, 2009, 2:29:40 PM12/8/09
to cerbe...@googlegroups.com
interesting,
I didn't realize our current locking mechanism was failing over in
some cases. I know it's not a global lock but rather a per project
lock.
Maybe its time to take a look at the locking system and add some improvements
> To unsubscribe from this group, send email to cerberusci+...@googlegroups.com.
I didn't realize our current locking mechanism was failing over in
some cases. I know it's not a global lock but rather a per project
lock.
Maybe its time to take a look at the locking system and add some improvements
somebox
Dec 8, 2009, 2:39:31 PM12/8/09
to Cerberus
I think in my case it may be because im testing different branches
within the same rails project (stable and trunk, for instance). Even
though I had specified different checkouts, databases and settings for
each branch build, they would still conflict sometimes (these are
Rails projects). I think that running them in series was what helped
more than the lock - I didnt realize there was a locking mechanism in
place.
BTW, love this app :) I'm so happy to be off of cruise control :)
Jeremy
within the same rails project (stable and trunk, for instance). Even
though I had specified different checkouts, databases and settings for
each branch build, they would still conflict sometimes (these are
Rails projects). I think that running them in series was what helped
more than the lock - I didnt realize there was a locking mechanism in
place.
BTW, love this app :) I'm so happy to be off of cruise control :)
Jeremy
Reply all
Reply to author
Forward
0 new messages