Nexus and chef

Chef Infra (archive)
1

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-.war, thing-.war,…,thing-.war.

2

Can’t you do a HEAD request on the resource, and look for a last
modified timestamp header to see if it has changed?

Upayavira

On Thu, 19 May 2011 12:22 -0700, "Yvonne Lam"
yvonne.z.lam@gmail.com 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-.war,
thing-.war,…,thing-.war.

3

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 yvonne.z.lam@gmail.com 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-.war, thing-.war,...,thing-.war.