Thanks for the tip, I had used lein-ancient in the past and it seems to have come along a bit since then.
How is it that you have this configured? Do you run lein ancient upgrade before each build that you want to check its dependencies? I tried this locally and I can't find a way to tell lein ancient to only try and upgrade certain libraries, rather than all or nothing. For example I have a dependency on incanter 1.5.5 - I don't want it to upgrade to 1.9.0 because it will break the build catastrophically just now... I do however want to whitelist it to my library, which I'm expecting to keep more current. R. On 17 February 2015 at 19:14, Michael Blume <blume.m...@gmail.com> wrote: > Related -- we run lein ancient as part of a lot of our builds so that we can > easily pick up dependencies with newer available versions. > > On Tue Feb 17 2015 at 11:13:44 AM Michael Blume <blume.m...@gmail.com> > wrote: >> >> 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. -- 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.
