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

查看:32
本文介绍了Jenkins:在两次作业运行之间存储变量的好方法是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个时间触发的作业,它需要检索存储在该作业的先前运行中的某些值.

I have a time-triggered job which needs to retrieve certain values stored in a previous run of this job.

有没有办法在 Jenkins 环境中的作业运行之间存储值?

Is there a way to store values between job runs in the 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 a 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.

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

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆