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.
