问题描述
（我已经在这里和其他地方看到过一些建议，包括NodeLabel插件来解决类似的问题，但是还没有找到一个实例来说明如何使用NodeLabel实现这个目的。 ）
现在，gerrit触发器基于我的一个项目的git仓库中的给定分支启动构建。
Right now a gerrit trigger starts a build based on a given branch in the git repo of one of my projects.
这将创建一个父作业P，它使用参数化触发器插件在两个不同操作系统（X1和Y1）的两个从属上产生两个项目构建（由两个标签标识）。
This creates ONE parent job P that uses the Parameterized Trigger plugin to spawn two more project builds (identified by two labels) on two slaves with two different OSes (X1 and Y1).
明天，我有一个新版本的Y1来构建为Y2，并且X1已被弃用。
Tomorrow, I have a new version of Y1 to build for called Y2, and X1 is deprecated. I can identify the valid targets for this version of my code within the code's git repo.
在这一点上，我有一个父类（P）和三个节点类型（X1， Y1 Y2）处理。因为分支，我还必须支持构建旧代码（对于X1和Y1）或新代码（仅Y2）的能力。
At that point I have a parent (P) and three node types (X1, Y1 Y2) to deal with. Because of branching I also must support the ability to build both legacy code (for X1 and Y1) OR new code (Y2 only).
我可以创建另一个作业Y2 （除了节点类型，它与Y1相同，它将构建限制为使用静态标签），然后在每个子作业的执行期间，我可以决定是早期中止作业（已弃用的目标）还是执行构建。然而，每次我构建我现在得到四个git克隆添加冗余负载和流量到git服务器：一个为父和一个为每个目标，包括两个我可以确定在第一个执行shell步骤过期！
I could create yet another job Y2 (which is identical to Y1 except for the node type it restricts the build to using a static label), and then during the execution of each child job I could decide whether to abort the job early (deprecated target) or perform that build. However, every time I build I now get four git clones adding redundant load and traffic to the git server: one for the parent and one for each target, including the two I could have determined to be obsolete during the first "Execute shell" step!
这听起来可能不太多，但是当我们进入OS Y9时，我们可以为给定的分支运行多达10个作业，其中8个不需要。这是不可能的。虽然最终较旧的操作系统目标将被修剪，但是在任何给定的时间都需要有几个版本可用，即使只需要一个版本。
This might not sound like much, but when we get to OS Y9 we could have up to ten jobs being run for a given branch, eight of which are unneeded... this is not tenable. Though eventually older OS targets would be pruned, several versions need to be available at any given time even if only one is required for the given build.
今天，第一个版本我在Jenkins上构建任何目标的步骤使用Execute shell来收集有用的信息传递给子作业。
Today, the first build step of my build on Jenkins for any target uses "Execute shell" to gather useful information to pass to the child jobs.
然而，子作业是硬编码的在触发/调用在其他项目上构建 - >要构建的项目字段（以及其他重要设置，例如它们如何和何时阻止！）如果相反，我可以在其中放置一个变量（或以某种方式引用变量I以编程方式设置），我可以简单地在shell步骤之前设置该变量，然后它将填充完全所需的子项目！子项目知道它们允许执行的节点/节点组。
The child jobs are, however, hard-coded in the "Trigger/call builds on other projects --> Projects to build" field (along with other important settings such as how and when they block!) If instead I could put a variable in there (or somehow refer to a variable I set programmatically), I could simply set that variable in the shell step before it, and then it'd be populated with exactly the sub-projects it requires! The subprojects "know" what nodes/groups of nodes they are allowed to execute on.
简而言之，我的项目执行一个脚本，该脚本设置一个变量，定义要调用的子项目，就好像我编辑了此构建的配置（例如，MY_PROJ_TO_BUILD =X1 Y1填充要构建的项目字段）。下一步继续以常规方式构建这些子项目。这就是我需要它做，当然不会失去任何当前的功能和没有直接黑客Jenkins。 （因为这些都是从gerrit触发的，有多个版本的gerrit和/或Jenkins运行不是一个可行的选择。）
In short, my project executes a script, that script sets a variable, that variable defines the sub-projects to call, much as if I edited the config for this build (e.g., MY_PROJ_TO_BUILD="X1 Y1" populates the "Projects to build" field). The next step continues by building those sub-projects in the usual way. That's all I need it to do and certainly without losing any current functionality and without directly hacking Jenkins. (Since these are triggering off of gerrit, having multiple versions of gerrit and/or Jenkins running isn't a viable option either.)
NodeLabel但我还没有看到如何有效地使用它的这种问题的例子（我看到的例子是非常模糊）。所以，如果你有一个例子适合账单或指针，我会很高兴看到它。同样，如果你有一个不同的想法/解决方案，我很高兴听到它。我可以想象为什么我希望工作（变量sub在项目构建字段）不，也许不能，但肯定运行使许多不必要的克隆只是为了确定目标的一个小子集需要一个给定的分支的构建是不是最佳的。
NodeLabel has been mentioned but I've yet to see an example of how to use it effectively for this kind of problem (the examples I've seen are extremely vague). So, if you have an example that fits the bill or a pointer to one I'd be glad to see it. Likewise, if you have a different idea/solution I'd be glad to hear it. I can imagine some reasons why what I wish worked (variable sub in the "projects to build" field) doesn't and perhaps cannot, but surely running making lots of unnecessary clones just to determine a small subset of targets are required for a given branch's build isn't optimal either.
（注意：这个是一个项目/ repo ...有几十个我处理的实际上，我不得不说，创建几个相同 - 但为节点类型 - 他们运行的每个子项目本身是一个far，但是它是我现在找到的唯一的方法，当确保向后构建兼容性，当几个目标可能需要为给定的分支构建构建。）
(Note: this is for one project/repo... there are dozens I'm dealing with actually, and I have to say creating several identical-but-for-the-node-type-they-run-on subprojects for each one is itself a farce... but it's the only way I've found up to now that ensures backward build compatibility when several targets may need to be build for a given branch build.)
推荐答案
只是一个想法，我不知道它是否会在你的情况下工作/帮助...
Just one idea, I'm not sure if it would work/help in your situation...
触发孩子作业通过URL访问，而不是通过Jenkins。项目脚本可以访问子作业启动的URL。
Trigger the child jobs via URL access rather than through Jenkins. The project script can access the URL(s) for the child job(s) to kick off.
这篇关于Jenkins，参数化构建和基于变量选择所需子项目和子节点的能力的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！