The PlatformLabeler plugin has been a real help for some of those cases of OS and platform values, and it handles them automatically.
On Tue, Apr 29, 2014 at 9:42 AM, Jeff <[email protected]> wrote: > Maybe this exists but I missed it, but I also wonder if there is a way to > inject system environment variables on any node (master/slaves) so that > things like OS name/family, architecture, OS distribution (e.g., 'Ubuntu > 14.04 LTS'), etc. could be already available. > > Seems redundant to have to manually specify labels that are inherent to > the slave environment. > > > On Tue, Apr 29, 2014 at 7:40 AM, Kevin Fleming (BLOOMBERG/ 731 LEXIN) < > [email protected]> wrote: > >> You are correct, the decision logic for choosing slaves only takes labels >> into account, it does not match up JDK requirements. You'll have to put the >> appropriate labels on your slaves as well. >> >> Rather than modifying the decision logic, though, a way to solve this >> problem would be for the configuration code that manages the list of >> installed JDKs on a slave to have an option to inject labels automatically >> into the slave's list of labels based on the installed JDKs. That would >> allow the normal label-based decision logic to work, but would eliminate >> the duplicate data entry (and the opportunity for mistakes). >> >> >> ----- Original Message ----- >> From: [email protected] >> To: [email protected] >> At: Apr 29 2014 07:51:24 >> >> As we need a lot of manually installed tools, we decided to have strictly >> separated slaves and provide rather lots of labels to get each project >> built on the right slave. >> This works really good so far. Now we thought we could spare at least the >> label for the JDK, as Jenkins in a sense has all needed information to pick >> the right slave for a needed JDK: >> * All used JDKs are provided in the Jenkins core configuration, and all >> of them are marked as "do not install automatically". >> * Each project has the "Used JDK" set to a particular JDK. >> * Each node has a list of all manually installed JDKs. >> Hence, if Jenkins needs to pick a Slave from the list of possible nodes, >> it can "see" which of those have the needed JDK for a particular project >> installed. >> Unfortunately it does not. In fact, it picks just ANY, even one that has >> not the needed JDK installed. >> >> Certainly this can be easily worked around by using another label for the >> JDK, but we think this is redenundant information. If Jenkins can >> auto-install a missing JDK, why can't it in turn not simply use a different >> slave if the JDK is missing for those not wanting to use auto-install? >> -- >> 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. >> > > > > -- > Jeff Vincent > See my LinkedIn profile at: > http://www.linkedin.com/in/rjeffreyvincent > > -- > 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. > -- Thanks! Mark Waite -- 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.
