哈德森:在两次作业之间存储变量的好方法是什么? [英] Hudson: What is a good way to store a variable between the two job runs?

问题描述

我有一个工作，需要知道由上次工作计算得出的值.

I have a job which needs to know a value calculated by the previous job run.

是否可以将其存储在Hudson/Jenkins环境中?

Is there a way to store it in the Hudson/Jenkins environment?

例如，我可以在shell脚本操作中编写类似next的内容:

E.g., I can write something like next in a shell script action:

XXX=`cat /hardcoded/path/xxx`
#job itself
echo NEW_XXX > /hardcoded/path/xxx

但是还有更可靠的方法吗?

But is there more reliable approach?

推荐答案

一些选项:

• 将数据存储在工作空间中.如果数据不是关键数据(即，在对工作空间进行核对时可以将其核对)就可以了.我只用它来缓存昂贵的计算数据，例如预建的库相关性.
• 将数据存储在文件系统中的某个固定位置.您将减少jenkins的独立性，从而使迁移+备份更加复杂-但可能不会太多.特别是如果您将数据存储在jenkins的某些自定义用户子目录中.并行构建也将很棘手，而分布式构建可能是不可能的. Jenkins有一个userContent子目录，您可以使用它-这样文件至少是jenkins安装的一部分，因此更容易迁移或备份.我为构建的(相当大的)代码覆盖率趋势文件执行此操作.
• 将数据存储在另一台计算机(例如数据库)上.设置起来比较复杂，但是您对本地计算机详细信息的依赖较少，并且分发起来可能更容易和并行构建工作.我这样做是为了维护实时变更日志.
• 将数据存储为构建工件.这意味着查看先前构建的工件.它是安全且可重复的，并且因为使用Uri来访问此类工件，所以对于分布式构建也可以.但是，您需要处理失败的构建(您应该回顾几个版本吗?从头开始?)，并且您将存储许多副本，如果大小为1KB，则很好，而如果大小为1GB，则不太好.这里的另一个缺点是，您可能需要很远地打开jenkin的安全设置，以允许匿名访问工件(因为您只是从uri下载).

• Store the data in the workspace. If the data isn't critical (i.e. it's ok to nuke it when the workspace is nuked) that should be fine. I only use this to cache expensive-to-compute data such as prebuilt library dependancies.
• Store the data in some fixed location in the filesystem. You'll make jenkins less self-contained and thus make migrations+backups more complex - but probably not by much; especially if you store the data in some custom user-subdirectory of jenkins. parallel builds will also be tricky, and distributed builds likely impossible. Jenkins has a userContent subdirectory you could use for this - that way the file is at least part of the jenkins install and thus more easily migrated or backed up. I do this for the (rather large) code coverage trend files for my builds.
• Store the data on a different machine (e.g. a database). This is more complicated to set up, but you're less dependant on the local machine's details, and it's probably easier to get distributed and parallel builds working. I've done this to maintain a live changelog.
• Store the data as a build artifact. This means looking at previous build's artifacts. It's safe and repeatable, and because Uri's are used to access such artifacts, OK for distributed builds too. However, you need to deal with failed builds (should you look back several versions? start from scratch?) and you'll be storing many copies, which is just fine if it's 1KB but less fine if it's 1GB. Another downside here is that you'll probably need to open up jenkin's security settings quite far to allow annonymous access to artifacts (since you're just downloading from a uri).

适当的解决方案将取决于您的情况.

The appropriate solution will depend on your situation.

这篇关于哈德森:在两次作业之间存储变量的好方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！