[chef] Re: nexus and chef


Chronological Thread 
  • From: Edward Sargisson < >
  • To:
  • Subject: [chef] Re: nexus and chef
  • Date: Mon, 30 May 2011 17:17:10 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=sypTkyVzzaR97/Ln5gnuLtFDXmHUA1+0TsTuvJ+Wye6J+7qdD4zzw6+X4xFIho1WzJ DV9zusxMse0QILyN37zgirnmIJV+6USoXuYqDdL69e79HvFLukG5x7l69xYXtWE/0VwA StfL70kHo27MUPj0p3USlUMRNlKmSl9Y/x7tQ=

Just came across this (yes, I'm way behind on my mail).

I haven't implemented this but I have a similar problem. My plan was
to have the build update a databag with the build id after a
successful build. Each node would store its current build id as node
data. Every chef run would compare the id in the databag with the id
in the node data and then do a deploy.

Note, this isn't exactly for maven but I think the idea may work for
maven. In my case I'm uploading my build artifacts to S3 with a unique
folder for each build id. When I've got a successful build then I want
to push it into the relevant environment.

Cheers,
Edward

On Thu, May 19, 2011 at 12:22 PM, Yvonne Lam 
< >
 wrote:
> I asked a couple of people at the chef meetup in Seattle about this; they
> gave me some good ideas and suggested that I ask the mailing list for more,
> so...  Does anyone have a nice way of using chef to deploy maven snapshots
> from nexus that they would be willing to share?  At my job, we've extended
> the deploy resource to know how to use the nexus search functionality to
> find artifacts and download them.  It works great, except that due to the
> nature of maven snapshots (*), it downloads snapshots whether it needs to or
> not.  Ideas so far:
> 1.  Hit nexus, download thing-1.0-SNAPSHOT.war snapshot, compare it to the
> existing one.  If they are the same, then tell the nexus/deploy resource
> somehow not to move the symlinks.  Issue:  I don't know how to tell the
> deploy resource not to move the symlinks.
> 2.  Give thing-1.0-SNAPSHOT.war a unique identifier (timestamp/build
> number/checksum) in a file in the target node's filesystem.  When the recipe
> next runs, scrape the nexus output to determine whether there is a new
> snapshot that needs to be downloaded.  If there isn't, don't download
> anything, and gracefully exit the nexus/deploy resource.  Issue:  I don't
> know how to make the graceful exit.
> 3.  Add code to check nexus for new snapshots separately, and only run the
> nexus resource if there are changes.  This is what I'm planning to implement
> for now.  Issues:  None really, except that (1) or (2) seem to me to be
> cleaner solutions if I could make them work.
> 4.  Add a build step to jenkins to run the chef client and update nodes when
> a new snapshot is built.  Issue:  I don't love the idea of adding an
> explicit dependency on jenkins, although I suppose I could be convinced
> otherwise.
> In case it matters, we're using nexus 1.5 open source, for which API
> documentation seems to be not quite available.
> Yvonne
> (*)  Basically, thing-1.0-SNAPSHOT.war refers to the most recent of
> thing-<timestamp1>.war, thing-<timestamp2>.war,...,thing-<timestampN>.war.



Archive powered by MHonArc 2.6.16.

§