CircleCI uses:
https://github.com/circleci/lein-version-specs
https://github.com/circleci/version-specs
Which can be used to set the version string arbitrarily.
Thanks,
Allen
On Wednesday, February 18, 2015 at 2:10:14 PM UTC-6, Michael Blume wrote:
>
> Afraid the plugin's internal.
>
> On Wed
Afraid the plugin's internal.
On Wed Feb 18 2015 at 2:34:32 AM Rick Moynihan
wrote:
> This sounds very close to what I'm looking for.
>
> Is this plugin opensourced or something you're using locally, as the
> closest thing I can find to what you describe is lein-git-version:
>
> https://github.c
This sounds very close to what I'm looking for.
Is this plugin opensourced or something you're using locally, as the
closest thing I can find to what you describe is lein-git-version:
https://github.com/cvillecsteele/lein-git-version
Which seems to follow project middleware approach you describe
We use a Leiningen plugin to set the version dynamically
https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md -- if
you skip down to "project middleware" you'll see how to create the kind of
plugin I'm talking about. Within the middleware function, we update the
:version key in the
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
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 al
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
wrote:
> What we do at Climate is avoid SNAPSHOT builds. Every build gets a version
> string with timestamp and
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
dependenc
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
