From jarl at gavia.dk  Mon Mar  8 11:04:25 2010
From: jarl at gavia.dk (Jarl Friis)
Date: Mon, 08 Mar 2010 17:04:25 +0100
Subject: [Cruisecontrolrb-users] cruise fails when projects have AR observer
 and there is no development database.
Message-ID: <m3mxyix0ja.fsf@zeus.intra.softace.dk>

Hi.

I just introduced an AR observer into my project. That made my CI
builds fail.

The error in the build log was this:
------------------------------------------------------------
home/cruise/.cruise/projects/pegasus/work cruise$ ruby1.8 -e "require 'rubygems' rescue nil; require 'rake'; load '/home/cruise/cruisecontrol-1.4.0/tasks/cc_build.rake'; ARGV << '--nosearch' << 'cc:build'; Rake.application.run; ARGV.clear"
rake aborted!
FATAL:  password authentication failed for user "pegasus_dev"
------------------------------------------------------------

pegasus_dev is the name of the database in my development
environment. On my CI machine (where cc.rb runs), there is no
DB nor DB user for development environment.

I confirmed that when I outcommented my configuration line enabling my
observer like this in config/environment.rb
------------------------------------------------------------
  # config.active_record.observers = :order_state_observer
------------------------------------------------------------
then things started to work again.

But why the sudden was CC.rb sudenly starting to use my development
environment?

So I got curious: I went to my CI machine
~/.cruise/projects/pegasus/work and ran (adding the --trace argument)
ruby1.8 --debug -e "require 'rubygems' rescue nil; require 'rake'; load '/home/cruise/cruisecontrol-1.4.0/tasks/cc_build.rake'; ARGV << '--nosearch' << '--trace' << 'cc:build'; Rake.application.run; ARGV.clear" 2> ~/trace.err 1> ~/trace.out

That showed that when configuring observer, the ENV['RAILS_ENV'] =
'test' statement in cc_build.rake:38 is not propagated properly to the
project rake task db:test:purge, it has to be set on a higher level.

So I added the argument 'RAILS_ENV=test' to the build command, and things work.

Here is a patch the the build model.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccrb.patch
Type: text/x-patch
Size: 1021 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20100308/f1ade6aa/attachment-0001.bin>
-------------- next part --------------

I have created ticket #278

Jarl


-- 
Jarl Friis
Gavia Technologies ApS
Om?gade 8, 2.sal
2100 K?benhavn ?.
Denmark
Phone:  +45 26 13 20 90
E-mail: jarl at gavia.dk
LinkedIn: www.linkedin.com/in/jarlfriis

From thewoolleyman at gmail.com  Tue Mar  9 00:30:20 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 8 Mar 2010 22:30:20 -0700
Subject: [Cruisecontrolrb-users] cruise fails when projects have AR
	observer and there is no development database.
In-Reply-To: <m3mxyix0ja.fsf@zeus.intra.softace.dk>
References: <m3mxyix0ja.fsf@zeus.intra.softace.dk>
Message-ID: <e3af97511003082130g22d16daao949e8e5b1931195e@mail.gmail.com>

On Mon, Mar 8, 2010 at 9:04 AM, Jarl Friis <jarl at gavia.dk> wrote:
> That showed that when configuring observer, the ENV['RAILS_ENV'] =
> 'test' statement in cc_build.rake:38 is not propagated properly to the
> project rake task db:test:purge, it has to be set on a higher level.

Thanks for the report Jarl, but I'd like to get more details before
sprinkling more RAILS_ENV around.

Why isn't RAILS_ENV propagated to db:test:purge?  It is just being
called via Rake::Task[task_name].invoke, which should pass it along.
Plus, db:migrate obviously has no problems...

Are you sure this isn't a bug in your app or the specific version of
Rails you are using?

-- Chad

From micah at riseup.net  Thu Mar 11 10:29:12 2010
From: micah at riseup.net (Micah Anderson)
Date: Thu, 11 Mar 2010 10:29:12 -0500
Subject: [Cruisecontrolrb-users] alternative tmp directory?
Message-ID: <87wrxidghj.fsf@pond.riseup.net>


I'm trying to determine how I can set an alternative tmp directory for
cruise session files. My /tmp has filled up a few times now with
ruby_sess.ff20ec1c310b4a78 (and similar) files. I cleaned them all out
yesterday, and have another 532 of them today. 

I've tried a few things so far. I have a tmp/sessions directory within
cruise itself, but that is not being used. In config/environment.rb
there is this:

  # Use the database for sessions instead of the file system
  # (create the session table with 'rake db:sessions:create')
  # config.action_controller.session_store = :active_record_store

So I uncommented that line and tried to run a 'RAILS_ENV=production rake
db:sessions:create' as it says, but that tells me:

undefined method `connection' for ActiveRecord::Base:Class

I thought perhaps that was because there was no config/database.yml, so
I created a cruise database and setup a database.yml with the right
environment and permissions, but that didn't make that error go away.

I'd appreciate any suggestions of things to try!

micah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20100311/68e02dbd/attachment.bin>

From micah at riseup.net  Thu Mar 11 10:34:11 2010
From: micah at riseup.net (Micah Anderson)
Date: Thu, 11 Mar 2010 10:34:11 -0500
Subject: [Cruisecontrolrb-users] Builds failing but not being reported
	as failed
References: <87y6sduxti.fsf@pond.riseup.net>
	<b85742420906010557q4feaa6f4l46f94623cf99f707@mail.gmail.com>
	<648eacf20906182301nfa01e4fy62d69621227932a2@mail.gmail.com>
Message-ID: <87k4tidg98.fsf@pond.riseup.net>


Ooops, I failed to see this follow-up message:

> Did this solve your problem, Micah?

In fact it did! Thanks! :)

micah

-- 
"It is no measure of health to be well adjusted to a profoundly sick society." - J Krishnamurti 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20100311/ac8210de/attachment.bin>

From jarl at gavia.dk  Fri Mar 12 02:36:53 2010
From: jarl at gavia.dk (Jarl Friis)
Date: Fri, 12 Mar 2010 08:36:53 +0100
Subject: [Cruisecontrolrb-users] cruise fails when projects have AR
 observer and there is no development database.
In-Reply-To: <e3af97511003082130g22d16daao949e8e5b1931195e@mail.gmail.com>
	(Chad Woolley's message of "Mon, 8 Mar 2010 22:30:20 -0700")
References: <m3mxyix0ja.fsf@zeus.intra.softace.dk>
	<e3af97511003082130g22d16daao949e8e5b1931195e@mail.gmail.com>
Message-ID: <m34okmhtyi.fsf@zeus.intra.softace.dk>

Chad Woolley <thewoolleyman at gmail.com> writes:

> On Mon, Mar 8, 2010 at 9:04 AM, Jarl Friis <jarl at gavia.dk> wrote:
>> That showed that when configuring observer, the ENV['RAILS_ENV'] =
>> 'test' statement in cc_build.rake:38 is not propagated properly to the
>> project rake task db:test:purge, it has to be set on a higher level.
>
> Thanks for the report Jarl, but I'd like to get more details before
> sprinkling more RAILS_ENV around.
>
> Why isn't RAILS_ENV propagated to db:test:purge? 

It never reaches that far, it never succeds to boot rails!

Even without an AR observer, I can see from the trace output that it
fails with some PGError exception which is probably caught by 'rescue
nil' statement (which in general is a bad way to handle
exceptions). Even the bulid output shows that it has attempted to do
something in the development environment. Before my patch the
dashboard shows two "Custom Build Artifacts" test.log and
development.log, and after my patch it only shows one!, namely
test.log. You can confirm this, right? This the case for any rails
project. When/if you can confirm this, you may ask yourself, why is
cruisecontrolrb producing a development.log. Nevertheless it is
interesting to see that the content of the development.log build
artifact has been executed on the test DB configuration, for example
the development.log contains "SET client_min_messages TO 'warning'",
but only my test DB configuration contains a "min_messages: warning"
setting, not development.

Even on your project a development.log is produced, right?

I think the reason the issue becomes fatal when using AR observers, is
that rails needs to connect to the database at rails boot time (that
is during load of environment configuration)

There is a difference between
$./script/console
Loading development environment (Rails 2.3.5)
>> RAILS_ENV='test'
(irb):1: warning: already initialized constant RAILS_ENV
=> "test"
>> 

and 

$ ./script/console test
Loading test environment (Rails 2.3.5)
>> 


The first way is the way cruisecontrolrb does it (without my patch),
the second way is the correct way, and that is what my patch
ensures. The first way even gives a warning, namely that the RAILS_ENV
is prior to booting rails. Actually my patch is equivalent to
'RAILS_ENV=test ./script/console' (setting the RAILS_ENV shell
environment variable prior to booting rails). Further the first way of
starting the console on my CI machine (where there is no development
DB) fails (now that I have introduced an AR observer) with the same
message as ccrb produced:
/var/lib/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/postgresql_adapter.rb:968:in `initialize':PGError: FATAL:  password authentication failed for user "pegasus_dev"

So I think it is time for some refactoring of ccrb in general to
ensure that RAILS_ENV is set prior to booting rails, prior to running
rake tasks just isn't early enough.

> It is just being called via Rake::Task[task_name].invoke, which
> should pass it along.  Plus, db:migrate obviously has no problems...
>
> Are you sure this isn't a bug in your app or the specific version of
> Rails you are using?

I am pretty sure... I am running the latests stable (2.3.5). I have
just followed standard rails guides, so the fact that rails connect to
the DB as early as during boot (but only when using AR observers), is
not my design and/or decision.

You can reproduce the problem, right? That also proves that it is not
only my app that is the problem.

Jarl



From sebastian.nowak at gmail.com  Thu Mar 18 16:42:15 2010
From: sebastian.nowak at gmail.com (Sebastian Nowak)
Date: Thu, 18 Mar 2010 21:42:15 +0100
Subject: [Cruisecontrolrb-users] CCrb configuration for many projects
Message-ID: <1cd6f2671003181342r54577f73w8e68ebcda4072570@mail.gmail.com>

Hi!
I have about 10 projects in my Cruise. I want to use metric_fu (roodi,
rcov, flay) metrics. Right now I have defined :cruise task in Rakefile
in each project. Is there any convention to manage cruise
configuration from one place? Gem? Plugin for Rails projects? Some
good habit also for custom artifacts?

-- 
Pozdrawiam, Sebastian Nowak
http://blog.sebastiannowak.net
XMPP: seban at chrome.pl

From thewoolleyman at gmail.com  Thu Mar 18 18:32:20 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 18 Mar 2010 15:32:20 -0700
Subject: [Cruisecontrolrb-users] CCrb configuration for many projects
In-Reply-To: <1cd6f2671003181342r54577f73w8e68ebcda4072570@mail.gmail.com>
References: <1cd6f2671003181342r54577f73w8e68ebcda4072570@mail.gmail.com>
Message-ID: <e3af97511003181532p57078fceo3e2f171b03db0e22@mail.gmail.com>

On Thu, Mar 18, 2010 at 1:42 PM, Sebastian Nowak
<sebastian.nowak at gmail.com> wrote:
> Hi!
> I have about 10 projects in my Cruise. I want to use metric_fu (roodi,
> rcov, flay) metrics. Right now I have defined :cruise task in Rakefile
> in each project. Is there any convention to manage cruise
> configuration from one place? Gem? Plugin for Rails projects? Some
> good habit also for custom artifacts?

It is all ruby, so you can abstract it to a class/module, and share it
across projects via svn externals or git submodules, or a gem.  Not
sure what you mean by custom artifacts...

From sebastian.nowak at gmail.com  Fri Mar 19 03:37:16 2010
From: sebastian.nowak at gmail.com (Sebastian Nowak)
Date: Fri, 19 Mar 2010 08:37:16 +0100
Subject: [Cruisecontrolrb-users] CCrb configuration for many projects
In-Reply-To: <e3af97511003181532p57078fceo3e2f171b03db0e22@mail.gmail.com>
References: <1cd6f2671003181342r54577f73w8e68ebcda4072570@mail.gmail.com>
	<e3af97511003181532p57078fceo3e2f171b03db0e22@mail.gmail.com>
Message-ID: <1cd6f2671003190037v6a86c3efte2b9b426cc96f2c8@mail.gmail.com>

On 18 March 2010 23:32, Chad Woolley <thewoolleyman at gmail.com> wrote:
> It is all ruby, so you can abstract it to a class/module, and share it
> across projects via svn externals or git submodules, or a gem. ?Not
> sure what you mean by custom artifacts...
> _______________________________________________

When I wrote 'custom artifacts' I mean all this stuff generated by metric_fu.


-- 
Pozdrawiam, Sebastian Nowak
http://blog.sebastiannowak.net
XMPP: seban at chrome.pl

From Nick.Adamson at generaldynamics.uk.com  Fri Mar 19 08:45:43 2010
From: Nick.Adamson at generaldynamics.uk.com (Nick.Adamson at generaldynamics.uk.com)
Date: Fri, 19 Mar 2010 12:45:43 -0000
Subject: [Cruisecontrolrb-users] Restricting concurrent builds across
	projects.
Message-ID: <634C6DD300F1EE46879A1A84896F361402A70A24@GDUKADH850.uk1.r-org.net>

Hi All.
 
We're using CCRB to automate our build process.
Currently CCRB is monitoring the trunk of our SVN repository.
we'd also like it to monitor some branches.
 
The issue that I can see coming up is that the box running our builds on
isn't a grate spec and we don't want it to try to build the trunk at the
same time that its building the branch.
Is there any way of setting a max number of concurrent builds or forcing
it to not monitor SVN when another build process is going on?
 
Any answers gratefully received.
 
Thanks.
Nick.
 
Nick Adamson
Software Engineer     
 General Dynamics United Kingdom Limited
Bryn Brithdir, Oakdale Business Park, Blackwood, South Wales, NP12 4AA 
Telephone: +44 (0)1495 23 6467     
Email: Nick.Adamson at generaldynamics.uk.com     
Website: www.generaldynamics.uk.com <http://www.generaldynamics.uk.com/>

To help reduce waste paper, please only print this email if you really
need to.

 


This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof.  General Dynamics United Kingdom Limited, Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in England and Wales No: 1911653.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20100319/6779270d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2071 bytes
Desc: Signature.gif
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20100319/6779270d/attachment-0001.gif>

From ruby at schmidtwisser.de  Sat Mar 20 08:40:05 2010
From: ruby at schmidtwisser.de (Gregor Schmidt)
Date: Sat, 20 Mar 2010 13:40:05 +0100
Subject: [Cruisecontrolrb-users] Restricting concurrent builds across
	projects.
In-Reply-To: <634C6DD300F1EE46879A1A84896F361402A70A24@GDUKADH850.uk1.r-org.net>
References: <634C6DD300F1EE46879A1A84896F361402A70A24@GDUKADH850.uk1.r-org.net>
Message-ID: <C3FA6964-3E72-40EA-BC83-B925B1FB003C@schmidtwisser.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Nick,

I'm not sure, if you have seen the option, but it"s quiet easy to  
disable concurrent builds completely. This usually works well for a  
smaller number of projects. CruiseControl.rb is also smart enough to  
build projects sitting on a branch, iif something in that branch  
changed. So in general, you should not see concurrent builds that often.


In your cruise_root (generally ~/.cruise) there is a file called  
site_config.rb. It is really well documented and should point you in  
the right directions if you want to disable concurrent build  
nevertheless.


Unfortunately I do not know an option to allow a limited number of  
concurrent builds, but I would be quiet interested to have this option  
as well. We are maintaining a public Redmine ci using cc.rb at http://ci.finn.de/ 
  with 18 different projects, observing only 2 different branches.  
This results in 9 projects scheduled for build simultaneously. Since  
an average build takes about 5 minutes, the final results are only  
available after 45 minutes. On the other hand, running them all at  
once would kill our server.


Best

Gregor


On 19.03.2010, at 13:45, <Nick.Adamson at generaldynamics.uk.com> <Nick.Adamson at generaldynamics.uk.com 
 > wrote:

> Hi All.
>
> We're using CCRB to automate our build process.
> Currently CCRB is monitoring the trunk of our SVN repository.
> we'd also like it to monitor some branches.
>
> The issue that I can see coming up is that the box running our  
> builds on isn't a grate spec and we don't want it to try to build  
> the trunk at the same time that its building the branch.
> Is there any way of setting a max number of concurrent builds or  
> forcing it to not monitor SVN when another build process is going on?
>
> Any answers gratefully received.
>
> Thanks.
> Nick.
>
> Nick Adamson
> Software Engineer
> <Signature.gif>General Dynamics United Kingdom Limited
> Bryn Brithdir, Oakdale Business Park, Blackwood, South Wales, NP12 4AA
> Telephone: +44 (0)1495 23 6467
> Email: Nick.Adamson at generaldynamics.uk.com
> Website: www.generaldynamics.uk.com
> To help reduce waste paper, please only print this email if you  
> really need to.
>
>
> This email and any files attached are intended for the addressee and  
> may contain information of a confidential nature. If you are not the  
> intended recipient, be aware that this email was sent to you in  
> error and you should not disclose, distribute, print, copy or make  
> other use of this email or its attachments. Such actions, in fact,  
> may be unlawful. In compliance with the various Regulations and  
> Acts, General Dynamics United Kingdom Limited reserves the right to  
> monitor (and examine for viruses) all emails and email attachments,  
> both inbound and outbound. Email communications and their  
> attachments may not be secure or error- or virus-free and the  
> company does not accept liability or responsibility for such matters  
> or the consequences thereof. General Dynamics United Kingdom  
> Limited, Registered Office: 100 New Bridge Street, London EC4V 6JA.  
> Registered in England and Wales No: 1911653.
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users


- --
Gregor Schmidt
Jungstr. 3
10247 Berlin

Festnetz:  +49 30 99 27 82 90
Mobil:     +49 151 23 06 00 60

schmidt at nach-vorne.eu
www.nach-vorne.eu


- --
Gregor Schmidt
Jungstr. 3
10247 Berlin

Festnetz:  +49 30 99 27 82 90
Mobil:     +49 151 23 06 00 60

schmidt at nach-vorne.eu
www.nach-vorne.eu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkukwiUACgkQEA6PB4V2Ye8mXgCeIgYpjwnvnu36oxAAxSlIQt0X
BAQAnRX8/CgNCBZSjOtdw6qgOl4WttT2
=RuI8
-----END PGP SIGNATURE-----

From thewoolleyman at gmail.com  Sat Mar 20 12:46:27 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sat, 20 Mar 2010 09:46:27 -0700
Subject: [Cruisecontrolrb-users] Restricting concurrent builds across
	projects.
In-Reply-To: <C3FA6964-3E72-40EA-BC83-B925B1FB003C@schmidtwisser.de>
References: <634C6DD300F1EE46879A1A84896F361402A70A24@GDUKADH850.uk1.r-org.net>
	<C3FA6964-3E72-40EA-BC83-B925B1FB003C@schmidtwisser.de>
Message-ID: <e3af97511003200946n14c335cfy13b023771329f197@mail.gmail.com>

On Sat, Mar 20, 2010 at 5:40 AM, Gregor Schmidt <ruby at schmidtwisser.de> wrote:
> Unfortunately I do not know an option to allow a limited number of
> concurrent builds, but I would be quiet interested to have this option as
> well. We are maintaining a public Redmine ci using cc.rb at
> http://ci.finn.de/ with 18 different projects, observing only 2 different
> branches. This results in 9 projects scheduled for build simultaneously.
> Since an average build takes about 5 minutes, the final results are only
> available after 45 minutes. On the other hand, running them all at once
> would kill our server.


Gregor,

Check out some of the polling and scheduled build options which were
added recently:

http://github.com/thoughtworks/cruisecontrol.rb/blob/master/config/cruise_config.rb.example#L22

With some combination of these options set differently across your
projects , you should be able to get builds triggered or run on a
schedule, but not all at the same time.

Oh, and thanks for helping out on the list :)

-- Chad

From Nick.Adamson at generaldynamics.uk.com  Tue Mar 23 04:48:03 2010
From: Nick.Adamson at generaldynamics.uk.com (Nick.Adamson at generaldynamics.uk.com)
Date: Tue, 23 Mar 2010 08:48:03 -0000
Subject: [Cruisecontrolrb-users] Restricting concurrent builds
	acrossprojects.
In-Reply-To: <e3af97511003200946n14c335cfy13b023771329f197@mail.gmail.com>
References: <634C6DD300F1EE46879A1A84896F361402A70A24@GDUKADH850.uk1.r-org.net><C3FA6964-3E72-40EA-BC83-B925B1FB003C@schmidtwisser.de>
	<e3af97511003200946n14c335cfy13b023771329f197@mail.gmail.com>
Message-ID: <634C6DD300F1EE46879A1A84896F361402A70D7F@GDUKADH850.uk1.r-org.net>

Hi Gregor and Chad.

Thanks for the info.

Thanks.
Nick.


-----Original Message-----
From: cruisecontrolrb-users-bounces at rubyforge.org
[mailto:cruisecontrolrb-users-bounces at rubyforge.org] On Behalf Of Chad
Woolley
Sent: 20 March 2010 16:46
To: cruisecontrolrb-users at rubyforge.org
Subject: Re: [Cruisecontrolrb-users] Restricting concurrent builds
acrossprojects.

On Sat, Mar 20, 2010 at 5:40 AM, Gregor Schmidt <ruby at schmidtwisser.de>
wrote:
> Unfortunately I do not know an option to allow a limited number of
> concurrent builds, but I would be quiet interested to have this option
as
> well. We are maintaining a public Redmine ci using cc.rb at
> http://ci.finn.de/ with 18 different projects, observing only 2
different
> branches. This results in 9 projects scheduled for build
simultaneously.
> Since an average build takes about 5 minutes, the final results are
only
> available after 45 minutes. On the other hand, running them all at
once
> would kill our server.


Gregor,

Check out some of the polling and scheduled build options which were
added recently:

http://github.com/thoughtworks/cruisecontrol.rb/blob/master/config/cruis
e_config.rb.example#L22

With some combination of these options set differently across your
projects , you should be able to get builds triggered or run on a
schedule, but not all at the same time.

Oh, and thanks for helping out on the list :)

-- Chad
_______________________________________________
Cruisecontrolrb-users mailing list
Cruisecontrolrb-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users


This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof.  General Dynamics United Kingdom Limited, Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in England and Wales No: 1911653.