Avoiding SNAPSHOT builds certainly solves the problem, but I was hoping to continue to either fully automate the process or use SNAPSHOTs between official releases library while integrating.
For example right now I have four private projects on our CI server that depend on a common library I am also working on - and then there are perhaps 3 or 4 additional projects by other developers within the organisation who may choose to use a release or on occaision a SNAPSHOT build of some of these libraries. Not to mention how I'd ultimately like to move to a model where the CI server is building and integrating on perhaps 3 or 4 different branches for each of those projects. I'm really after advice on how to configure Jenkins to help automate this process. You mentioned including the git commit in the version number for snapshot builds. This is a great idea, but how can I get Jenkins and leiningen to do this for me? I know I can access the commit/build_id through environment variables but how can I easily insert them into the leiningen project.clj version number? Without automation here I feel like I'll literally spend my life updating version numbers. R. On 17 February 2015 at 19:13, 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.
