[
https://issues.jenkins-ci.org/browse/JENKINS-13006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
domi updated JENKINS-13006:
---------------------------
Issue Type: New Feature (was: Bug)
have you looked at the feature this plugin adds to the "ParameterizedTrigger
plugin"?
would that be of any help for you? The ParameterizedTrigger plugin allows you
to read parameters from a file.
https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin#NodeLabelParameterPlugin-ParameterizedTriggerplugin
> Allows node labels to be read from a file.
> ------------------------------------------
>
> Key: JENKINS-13006
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13006
> Project: Jenkins
> Issue Type: New Feature
> Components: nodelabelparameter
> Affects Versions: current
> Environment: Windows Server 2008 SP2
> Reporter: Richard Taylor
> Assignee: domi
> Fix For: current
>
>
> Allow node labels to be read from a file and selected from a list as a job
> parameter. (Ref: functionality from Extended Choice Parameter plugin)
> Motivation.
> We have a set of jobs which can be run an any development or release branch.
> The branch is a parameter of the job.
> We have a set of large branches which can take several hours to checkout from
> fresh.
> Jenkins has support for tying Jobs to nodes but with very large branches this
> is a poor fit. The checkout and sync of a branch is the most significant
> factor in build time so the key to keeping builds fast is to reuse the same
> branch on the same slave for different job. i.e. The branch is tied to the
> slave and NOT the job.
> We already have a script which will write out available branches to a text
> file that is used by the Extended Choice Parameter plugin. The plan was then
> to use this branch choise parameter as a node lablel, dynamically selecting
> the correct set of slaves given the selected branch for the job.
> Unfortunately the 'Restrict where this project can be run' label does not
> support variable expansion.
> ATM we have a hybrid solution where build which need to be fast are
> duplicated and hardcoded for each branch on a different set of slaves. Build
> which needs to be unique (such as package builds which need a sequential
> build number for versioning) have to checkout the branch on the slave and
> incure the sync overhead which can be several hours.
> Any help greatly appreciated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
