Well, this requires that the slave be accessible, which would not be true for cloud slaves that are spawned on demand :-)
It's an interesting idea, but there would need to be some sort of 'mapping' mechanism to take the raw strings from the slave's environment and turn them into suitable labels. Note also that most of this information is not really in 'environment variables' on the slave, but is extractable through various tools. ----- Original Message ----- From: [email protected] To: [email protected] At: Apr 29 2014 11:43:30 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. ------------------------------------------------------------------------------- -- 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.
