首页 > 解决方案 > Artifactory Continuous integration approach

问题描述

So far, I have artifactory hooked up to jenkins such that jenkins is pushing up artifacts to artifactory on every push to master. I doubt I'll be able to influence the other devs to alter their behavior and it seems like pushing artifacts to artifactory in this manner is a waste. Enter build retention, which seems like a nice solution.

So what I'm looking for is some advice on the best course of action here. Googling for this hasn't been fruitful.

It seems like a good idea to have, say retention for up to the last 20 or so builds. The artifacts from these builds will be candidates subject to further testing and usage. Then should one be chosen as a release candidate, to be included as part of some superset release package, it seems logical that I would want to ensure that the selected build is retained indefinitely in the interests of traceability and reproducibility. If I did this, all of the interim or otherwise ignored candidate builds would then disappear as part of a retention policy.

Is this a sensible strategy? If so, how would one execute it? I understand how to deploy and set retention policies as per artifactory's documentation but not about the prospect of "unsetting" it on blessed builds. I have read that build promotion can be employed to a achieve something like this but in the context of promotion it seems to imply copying to another repository which isn't necessarily what I am after. (Though I am open to guidance on best practice in this regard.)

Thanks!

标签: jenkins-pipelineartifactory

解决方案


不是关于在祝福构建上“取消”它的前景。

这就是快照和发布的概念派上用场的地方。

只需推送到两个不同的 Artifactory 本地存储库,每个存储库都有自己的保留策略:

  • 快照一个 20 天(您可以一遍又一遍地覆盖相同的版本,工件保留该版本工件的时间戳修订)
    也设置Max Unique Snapshots为 20。
  • 0 天(无限保留)用于生产的祝福神器。

推荐阅读