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.
On 10 March 2014 21:47, Les Mikesell <[email protected]> wrote: > On Mon, Mar 10, 2014 at 4:26 PM, Stephen Connolly > <[email protected]> wrote: > > > >> Nothing at all wrong with the idea. But I can take any mapping of one > >> thing to another and mistype it or misunderstand it - or have the > >> computer put stuff in the wrong character set so what I see isn't what > >> jenkins will try to map. What I want is a way to have the mapping > >> done and check the results (by executing them to the extent possible) > >> before committing it. And I do call mapping one thing to another > >> magic if there isn't a way to trace your way through it. > > > > > > How can you verify that the environment you typed in to your build job of > > "java-1.7" and "maven-3.2.1" is correctly mapped to the tool installer > names > > you have typed into the CI system of "java-1.7" and "maven-3.2.1" > > That's equally awkward. I do that by reading the console log of the > failed jobs. But I'd rather not be doing even more of that. > > > Where would it make sense - except on the CI server - to validate those > > labels? > > Basically I want things to run on a developer's desktop the same as > they do in jenkins. So the jenkins environment settings and tool > locations are in fact only supposed to make up for any differences > between a local developer's layout and the node where jenkins > dispatches the job. They shouldn't be some new thing that doesn't > really exist. > > > The fancier mapping is config in Jenkins to allow Jenkins to understand > that > > e.g. "jdk-1.7" means "java-1.7"... in other words this is about telling > > jenkins what the labels in CI mean... that is config that only makes > sense > > to the CI server. > > Yes, but we need a way to cut through all the unnecessary abstraction > layers back to what a developer actually does locally. And I'm sure > a programmer's answer to that would be that we need another layer of > abstraction... > > -- > Les Mikesell > [email protected] > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
