jenkins 持续交付与共享工作区 [英] jenkins continuous delivery with shared workspace

问题描述

我们每天晚上都有一项 Jenkins 工作(生产)来构建可交付成果.我们还有另一项工作 (ProductionPush)，它在第二天通过专有协议将可交付成果推送到生产机器.这是因为某些生产机器仅在白天的特定时间可用(这也让我们有机会修复任何最后一刻的构建中断).ProductionPush 需要访问由 Production 作业构建的交付物(因此它需要访问相同的工作空间).我们有多个节点和并发构建(因此有不可预测的工作空间)，并且由于资源有限，我们不希望将作业绑定到固定的节点/工作空间.

We have one Jenkins job (Production) to build a deliverable every night. We have another job (ProductionPush) that pushes out the deliverable over a proprietary protocol to production machines the next day. This is because some production machines are only available during certain hours during the day (It also gives us a chance to fix any last-minute build breaks). ProductionPush needs access to the deliverable built by the Production job (so it needs access to the same workspace). We have multiple nodes and concurrent builds (and thus unpredictable workspaces) and prefer not to tie the jobs to a fixed node/workspace since resources are somewhat limited.

1. 如何确保两个作业共享相同的工作空间，并确保 ProductionPush 仅在 Production 成功的情况下在第二天的固定时间运行——无需修复两个作业都用完同一个节点/工作区?我知道 Parameterized Trigger Plugin 可能会对此有所帮助，但是它似乎没有延时能力，12小时对于安静的时间来说似乎太长了.

1. How to make sure both jobs share the same workspace and ensure that ProductionPush runs at a fixed time the next day only if Production succeeds -- without fixing both jobs to run out of the same node/workspace? I know the Parameterized Trigger Plugin might help with some of this but it does not seem to have time delay capability and 12 hours seems too long for a quiet period.

共享工作区是个坏主意吗?

Is sharing the workspace a bad idea?

推荐答案

答案 2:是的，共享工作区是个坏主意.存在文件锁定的可能性.存在工作区被消灭的问题.只是不要这样做...

Answer 2: Yes, sharing workspace is a bad idea. There is possibility of file locks. There is the issue of workspace being wiped out. Just don't do it...

答案 1:您需要的是归档构建的工件.这样，特定构建的工件(按构建编号)将始终可用，无论另一个构建是否正在运行，或者工作区处于什么状态

Answer 1: What you need is to Archive the artifacts of the build. This way, the artifacts for a particular build (by build number) will always be available, regardless of whether another build is running or not, or what state the workspaces are in

• 在您的构建作业中，在构建后操作下，选择归档工件
• 指定要存档的工件(您可以使用以下组合)
  a) 您可以全部存档:*.*
  b) 您可以使用通配符存档特定文件:/path/to/file_version*.zip
  c) 您可以忽略中间目录，例如:**/file_version*.zip
• 为了避免许多工件的存储问题，在配置顶部，您可以选择放弃旧构建，点击高级按钮，然后玩Days to保留工件和最大构建数量以保留工件.请注意，这两个设置不控制实际构建的保留时间(其他设置控制)

• In your build job, under Post-build Actions, select Archive the artifacts
• Specify what artifacts to archive (you can use a combination of below)
  a) You can archive all: *.*
  b) You can archive a particular file with wildcards: /path/to/file_version*.zip
  c) You can ignore the intermediate directories like: **/file_version*.zip
• To avoid storage problems with many artifacts, on the top of configuration you can select Discard Old Builds, Click Advanced button, and play around with Days to keep artifacts and Max # of builds to keep with artifacts. Note that these two settings do not control for how long the actual builds are kept (other settings control that)

• 在构建历史中，选择您想要的任何以前的构建.
• 除了 SCM 更改和修订数据之外，您现在还有一个构建工件链接，在该链接下您可以找到该特定构建的所有工件.莉>
• 例如，您还可以使用 Jenkins 的永久链接访问它们
  http://JENKINS_URL/job/JOB_NAME/lastSuccessfulBuild/artifact/ 然后是工件的名称.

• In the build history, select any previous build you want.
• In addition to SCM changes and revisions data, you will now have a Build Artifacts link, under which you will find all the artifacts for that particular build.
• You can also access them with Jenkins' permalinks, for example
  http://JENKINS_URL/job/JOB_NAME/lastSuccessfulBuild/artifact/ and then the name of the artifact.

我在这里广泛解释了如何从另一个部署作业(在您的示例中为ProductionPush)访问以前的工件:
如何推广来自 Jenkins 的另一份工作的特定内部版本号?

I've extensively explained how to access previous artifacts from another deploy job (in your example, ProductionPush) over here:
How to promote a specific build number from another job in Jenkins?

如果您的要求是始终将最新版本部署到生产环境，您可以跳过上述链接中promotion 的配置.只需按照 deploy 作业的配置步骤操作即可.一旦您有了部署作业，如果它总是同时运行，只需配置它的定期构建参数.或者，您可以创建另一个作业，根据您想要的任何条件触发 deploy 作业.

If your requirements are to always deploy latest build to Production, you can skip the configuration of promotion in the above link. Just follow the steps for configuration of the deploy job. Once you have your deploy job, if it is always run at the same time, just configure its Build periodically parameters. Alternatively, you can have yet another job that will trigger the deploy job based on whatever conditions you want.

在上述任一情况下，如果您的默认选择器设置为最新成功构建(如上面链接中所述)，最新构建将被推送到生产

In either case above, if your Default Selector is set to Latest successful build (as explained in the link above), the latest build will be pushed to Production

这篇关于jenkins 持续交付与共享工作区的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！