如何从 Jenkins 的另一份工作中推广特定的内部版本号?

问题描述

我从 Jenkins 安装了 Promoted Build Plugin，现在我在从现有作业升级构建时遇到了一些麻烦.这是场景:

I installed the Promoted Build Plugin from Jenkins and now I'm facing some troubles to promote a build from an existing job. Here is the scenario:

1. 现有的 Nightly Build 作业每天晚上运行，运行所需的所有测试和指标；

1. There is an existing Nightly Build job that runs every night running all the tests and metrics needed;

现有的 Deploy Build 接受参数 ${BUILD_NUMBER} 并部署具有 Nightly Build 中相应 ${BUILD_NUMBER} 的构建

There is an existing Deploy Build that accepts a parameter ${BUILD_NUMBER} and deploys the build that has the corresponding ${BUILD_NUMBER} from the Nightly Build

• 说 [Nightly Build] 运行并成功构建了工件 #39
• 现在我可以运行 [Deploy Build] 作为参数传入 #39
  • 来自 [Nightly Build] #39 的工件将被部署

  到目前为止一切顺利.现在是我想添加 Build Promotions...

  So far so good. Now is the part where I want to add the Build Promotions...

  有没有办法从 Deploy Build 推广 Nightly Build #39(注意它之前已经构建过)>?或者甚至可能来自其他地方，坦率地说，我有点迷失在这里:(

  Is there a way to promote the Nightly Build #39 (notice that it was already built before) from the Deploy Build? Or maybe even from somewhere else, quite frankly I`m kind of lost here :(

  我没有看到它们有明确的上游/下游关系，因为它们没有:在执行过程中总是运行这个构建然后另一个 - [Deploy Build] 有时只执行并且并不总是在 [Nightly Build] 之后.

  I don`t see them with a clear Upstream/Downstream relationship, because they don't have a: always runs this build and then the other during the execution - the [Deploy Build] is executed sometimes only and not always after the [Nightly Build].

  推荐答案

  更新自 Parameterized Trigger Plugin 2.23 版:

  2.23+ 版本 行为改变了(感谢 AbhijeetKamble 指出).调用 (build) 作业的预定义参数部分传递的任何参数都必须存在于被调用的 (部署) 作业.此外，被调用的工作参数的限制适用，所以如果被调用的工作的参数是一个选择，它必须预先填充所有可能的值(来自促销).或者只使用 Text 参数类型.

  Update as of version 2.23 of Parameterized Trigger Plugin:

  With version 2.23+ behavior changed (thanks AbhijeetKamble for pointing out). Any parameter that is being passed by Predefined Parameters section of calling (build) job has to exist in the called (deploy) job. Furthermore, the restrictions of called job's parameters apply, so if the called job's parameter is a choice, it has to have all possible values (from promotions) pre-populated. Or just use Text parameter type.

  是的，我有完全相同的设置:一个 build 作业(基于 SVN 提交)和手动执行的 deploy 作业.当用户从构建作业中选择任何构建(包括旧构建)时，他们可以转到推广状态链接并执行各种部署推广，例如Deploy to DEV、Deploy to QA等

  Yes, I have the exact same setup: a build job (based on SVN commits) and manually executed deploy job. When the user selects any build from the build job (including older builds), they can then go to Promotion Status link and execute various deploy promotions, for example Deploy to DEV, Deploy to QA, etc

  • 您将需要这些插件:参数化触发器插件、Promoted Builds Plugin
  • 您还需要为此构建作业设置默认的归档工件构建后操作.
  • 勾选标记在以下时间促进构建
  • 定义名称部署到 DEV"
  • 在标准复选标记下仅在手动批准时
  • 在操作下使用在其他项目上触发/调用构建
  • 在要构建的项目中，在此处输入部署作业的名称
  • 选中标记阻止，直到触发的项目完成构建
  • 如果触发的构建更差或等于，则将此构建标记为失败:失败(根据部署作业的状态进行调整)
  • 预定义参数(代码 A)
  • You will need these plugins: Parameterized Trigger Plugin, Promoted Builds Plugin
  • You will also need to setup default Archive the Artifacts post-build action on this build job.
  • Check mark Promote builds when
  • Define Name "Deploy to DEV"
  • Under Criteria check mark Only when manually approved
  • Under Actions use Trigger/call builds on other projects
  • In Projects to build enter the name to your deploy job here
  • Check mark Block until the triggered projects finish their builds
  • Mark this build as failure if the triggered build is worse or equal to: FAILURE (adjust according to statuses of your deploy job)
  • Predefined parameters (Code A)

  代码 A:

  Server=IP_of_my_dev_server`
  Job=$PROMOTED_JOB_NAME`
  BuildSelection=<SpecificBuildSelector><buildNumber>$PROMOTED_NUMBER</buildNumber></SpecificBuildSelector>
  

  在上面的预定义参数部分中，= 左侧的名称是在您的部署作业中定义的参数.= 的右侧是执行此促销时将分配给这些参数的值.定义三个参数Server、Job 和BuildSelection.

  Above, in the Predefined parameters section, the name to the left of = are the parameters that are defined in your deploy job. And to the right of = are the values that will be assigned to those parameters when this promotion executes. Defines three parameters Server, Job and BuildSelection.

  参数Server= 是我自己的，因为我的部署作业可以部署到多个服务器.但是，如果您的deploy 作业被硬编码为始终部署到特定位置，则您不需要这样做.

  The parameter Server= is my own, as my deploy job can deploy to multiple servers. However if your deploy job is hardcoded to always deploy to a specific location, you won't need that.

  Job= 参数是必需的，但参数的名称取决于您在部署作业中设置的内容(我将在那里解释配置).值 $PROMOTED_JOB_NAME 必须保持原样.这是提升过程知道的一个环境变量，并引用回您的构建作业的名称(配置了提升过程的那个)

  The Job= parameter is required, but the name of the param depends on what you've setup in your deploy job (I will explain configuration there). The value $PROMOTED_JOB_NAME has to remain as is. This is an environment variable that the promotion process is aware of and refers back to the name of your build job (the one where promotion process is configured)

  BuildSelection= 参数是必需的.这整条线必须保持原样.传递的值是 $PROMOTED_NUMBER，促销再次意识到这一点.在您的示例中，它将是 #39.

  The BuildSelection= parameter is required. This whole line has to remain as is. The value passed is $PROMOTED_NUMBER, which once again the promotion is aware of. In your example, it would be #39.

  在被触发的项目完成构建之前阻止复选标记将使升级过程等到部署作业完成.如果没有，升级过程将触发部署作业并成功退出.等待 deploy 作业完成的好处是，如果 deploy 作业失败，升级星也会被标记为失败.

  The Block until the triggered projects finish their builds check mark will make the promotion process wait until the deploy job finished. If not, the promotion process will trigger the deployment job and quit with success. Waiting for the deploy job to finish has the benefit that if the deploy job fails, the promotion star will be marked with failure too.

  (这里有一点要注意:promotion star 会在同时 deploy 作业正在运行时显示成功.如​​果有部署失败，它只会在之后变为失败deploy 作业完成了.合乎逻辑...但如果您在部署完成之前查看促销明星可能会有点混乱)

  (One little note here: the promotion star will appear successful while the deploy job is running. If there is a deploy failure, it will only change to failure after the deploy job finished. Logical... but can be a bit confusing if you look at the promotion star before the deployment completed)

  • 您将需要 Copy Artifacts 插件
  • 在此构建已参数化
  下
  • 使用 name Server 配置 Choice(或 Text) 类型的参数(此名称必须与促销的 中的配置匹配预定义参数在上一节)
  • 选择:输入促销活动的预定义参数可能使用的服务器 IP 列表(请参阅下面的更新说明)
  • 使用 name Job 配置 Choice(或 Text) 类型的参数(此名称必须与促销的 中的配置匹配预定义参数在上一节)
  • 选择:默认输入构建作业的名称.(我们配置的预定义参数中的 Job=).此外，如果没有从促销的预定义参数传递的值，则将使用第一个选择值.如果您在 build 和 deploy 作业之间存在一对一的关系，您可以在升级配置中省略 Job= 参数.
  • 更新: 自参数化触发器 2.23 版起，部署 作业配置中的可用选项必须具有来自促销预定义参数的所有可能值.如果您不想要该限制，请使用文本"而不​​是选择"
  • 使用名称配置复制工件的构建选择器类型的参数:BuildSelection
  • 默认选择器:最新成功构建
  • 在构建步骤下
  • 配置从另一个项目复制工件
  • 在项目名称中输入${Job}
  • 在哪个构建选择由构建参数指定
  • 在参数名称中输入BuildSelection(没有${...}！)
  • 相应地为您的工件配置其余部分，这些工件将从 build 作业复制到 deploy 作业的工作区
  • 根据需要在 deploy 作业中使用复制的工件以进行部署
  • You will need Copy Artifacts plugin
  • Under This build is parameterized
  • Configure a parameter of type Choice (or Text) with name Server (this name has to match with configuration in promotion's Predefined Parameters in previous section)
  • Choices: Enter list of possible server IPs that would be used by the promotion's Predefined Parameters in previous section (see update note below)
  • Configure a parameter of type Choice (or Text) with name Job (this name has to match with configuration in promotion's Predefined Parameters in previous section)
  • Choices: Enter the name of your build job as default. (the Job= from Predefined parameters that we configured). Also, if there is no value passed from promotion's Predefined parameters, the first choice value will be used. If you have a 1-to-1 relationship between the build and deploy jobs, you can omit the Job= parameter in promotion's configuration.
  • Update: since version 2.23 of Parameterized Trigger, the available choices in the deploy job configuration have to have all possible values coming from the promotion's predefined parameters. If you don't want that limit, use "Text" instead of "Choice"
  • Configure a parameter of type Build selector for Copy Artifact with name: BuildSelection
  • Default Selector: Latest successful build
  • Under Build steps
  • Configure Copy artifacts from another project
  • In Project name enter ${Job}
  • At Which build choose Specified by a build parameter
  • In Parameter Name enter BuildSelection (without ${...}!)
  • Configure the rest accordingly for your artifacts that will be copied from build job to deploy job's workspace
  • Use the copied artifacts inside the deploy job as you need in order to deploy

  现在，通过上述 deploy 作业，您可以手动运行它并从 build 作业中选择要部署的构建编号(上次构建、上次成功、通过内部版本号等).您可能已经对其进行了非常相似的配置.build 作业上的 promotion 将基本上执行相同的操作，并根据执行的升级提供内部版本号.

  So now, with the above deploy job, you can run it manually and select which build number from build job you want to deploy (last build, last successful, by build number, etc). You probably already have it configured very similarly. The promotion on the build job will basically execute the same thing, and supply the build number, based on what promotion was executed.

  如果您对说明有任何问题，请告诉我.

  Let me know if you got any issues with the instructions.

  这篇关于如何从 Jenkins 的另一份工作中推广特定的内部版本号?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！