What we do at Climate is avoid SNAPSHOT builds. Every build gets a version
string with timestamp and git commit. If an upstream library is changed,
it's up to downstream maintainers to update their dependency on it. If you
update a dependency and your build fails, you a) don't update your
dependency just yet b) complain to the library maintainer that their new
version breaks your project.

On Tue Feb 17 2015 at 9:51:18 AM Rick Moynihan <rick.moyni...@gmail.com>
wrote:

> Hi all,
>
> At work, we use Jenkins to continuously integrate our Clojure projects
> which are factored into both applications and a small number of
> supporting libraries; all of which use Leiningen as their project
> build tool.
>
> Leiningen builds each project, and runs its tests; and then if they
> pass it lein installs the project jar into the local ~/.m2 repo and
> triggers any dependent builds to start.  The dependencies then start
> building and pick up the latest SNAPSHOT build from the ~/.m2
> directory.
>
> This works ok; but it has a relatively major flaw, which is that just
> because a project passes its local tests; it doesn't mean that it
> hasn't broken an upstream library.  When this happens the broken
> library is left in the shared ~/.m2 directory - breaking other builds
> and generally lying around causing havoc.
>
> Fortunately this rarely happens in practice; but it is a potential
> cause of hard to diagnose (unrepeatable build) problems - especially
> when using snapshot builds - which is what I think we want to use for
> tracking branches until we
>
> We currently use the Jenkins leiningen plugin, but I don't think it
> supports a more sophisticated setup than this.
>
> I was wondering if anyone with experience of running robust CI builds
> (with Jenkins) might have any ideas about to solve this in a more
> robust manner??
>
> Many thanks,
>
> Rick
> --
> http://twitter.com/RickMoynihan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to