On Mon, Mar 10, 2014 at 5:08 PM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> You cannot force developers to call their java version the exact same as
> everyone else... there is always some reason why people name them
> differently... so you will always need a mapping layer... a smart mapping
> layer is easy to config.
>
Being smart isn't quite the point in this context. Being repeatable
across developers and jenkins is. Which means you do need a way to
know the exact version of everything regardless of the abstractions
that try to hide them and create variable results in spite of having
everything else under version control. Is there - or could there be
- a rest-ish way to ask jenkins how it would interpret the
abstractions and (a) save that in a file to freeze it in the SCM along
with the abstraction and (b) reverse-engineer it back to the local
environment that jenkins is supposed to be abstracting so it could
execute there.
At least within a jenkins job setup things like the tool locations do
a little consistency checking, like presenting a drop-down of
configured choices - but the stuff in your file doesn't have to match
anything and if the jenkins config changes your build will break - or
worse, rebuilding the same source version will build something
different with no way to track why,
--
Les Mikesell
lesmikes...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
