【问题标题】:Jenkins: Use Archived Artifact in Promoted BuildJenkins:在升级构建中使用存档工件
【发布时间】:2013-08-08 22:30:20
【问题描述】:

我已将一个工件存档为构建的最后一步,它可以像这样使用:https://xxx.ci.cloudbees.com/job/xxx/52/artifact/target/xxx-1.2.1-SNAPSHOT-r8304-20130807-1507-app.zip

如何在我的推广过程中轻松访问该工件?请注意,我需要访问特定的版本,而不是最新的成功版本。

提升过程的目标是将工件复制到 S3,我们的部署作业将从那里进一步处理它。所以我可能会将构建 #52 提升到开发(将其复制到特定的 S3 存储桶),然后将构建 #50 提升到生产等等。

理想情况下,我可以在 shell 脚本中访问工件以重命名文件等。是否有环境变量可以访问构建的存档工件,但我找不到或应该如何完成? $BUILD_URL$JOB_URL 已经特定于提升过程,并且不会在提升作业的 shell 脚本中指向构建本身。

使用复制工件插件,我只能在升级过程中从其他构建复制工件,我不需要这样做。

【问题讨论】:

    标签: java deployment jenkins cloudbees


    【解决方案1】:

    我相信我已经找到了解决方案。

    总结

    • 不要使用固定链接指定
    • 使用特定构建并将构建号设置为${PROMOTED_NUMBER}

    解决方案

    先决条件

    • 必须安装Copy Artifact Plugin
    • 归档您希望促销访问的工件
      • 构建后操作中添加操作归档工件并将要归档的文件设置为您希望推广访问的任何内容。
    • 不要丢弃旧工件
      • 在作业配置中,取消选择丢弃旧版本或确保其设置将保留工件只要您想推广您的版本。

    促销设置:

    像往常一样使用名称和条件设置您的升级版本。

    在“操作”部分添加操作从其他项目复制工件,并设置这些值。

    • 项目名称:${PROMOTED_JOB_NAME}
    • 哪个版本:特定版本
    • 内部版本号:${PROMOTED_NUMBER}
    • 要复制的工件:path/to/your/artifacts/**
    • 目标:${BUILD_TAG}

    然后添加您真正想做的操作。例如,添加操作 Archive the artifacts 以保存工件。请记住在您的路径前加上 ${BUILD_TAG} 前缀,例如${BUILD_TAG}/path/to/your/artifacts/**

    说明原因

    复制工件

    您现在可能知道,促销不应期望访问构建工作区的内容。它可能在不同的服务器上执行,并且可能根本无法访问任何工作区或来自较旧或较新版本的工作区。因此,需要将您要使用的工件复制到当前工作区。

    这也是设置Target值的原因。工作空间可能会被其他构建或促销活动污染。将 target 设置为 ${BUILD_TAG} 通过创建升级过程独有的文件夹来防止与工作区中已有的文件发生任何冲突。

    ${PROMOTED_*} 变量

    正如您所说,正常的构建变量指的是提升过程本身,但提升的构建插件定义了一些 environment variables 来指代实际的构建。

    固定链接

    在 Jenkins 上下文中,permalinks 仅指指向某种类型的最新构建或最新促销的特殊链接。这就是为什么您将始终获得最新版本的原因

    在我的 Jenkins 版本中,下拉菜单被替换为文本框。将 URL 写入特定构建(如 http://jenkins/job/myjob/59/)是 not recognized 作为特殊永久链接之一,复制 will thus fail

    【讨论】:

    • 这确实选择了正确的构建。相当晦涩,但很好的解决方案!
    • 这应该包含在“Promoted Builds”文档中
    【解决方案2】:

    您可以使用 Copy Artifact 插件。将其设置为从主项目复制工件,并选择由永久链接指定,其中永久链接为最新促销:此促销过程

    (注意,由于这里的升级配置是指自己,所以不能一步添加这样的升级:必须在没有构建步骤的情况下添加促销,保存,然后返回并添加构建步骤。)

    【讨论】:

    • 我觉得命名有点混乱,但这绝对是朝着正确方向迈出的一步。做了一个小测试,我经历了以下行为:第一个提升过程采用当前工件。任何额外的部署只能部署当前或以后的工件。如果我已经为特定提升提升了 build #60,尝试提升 #59 将再次部署 #60。我需要讨论这个问题,但这可能是避免旧部署的好方法。
    • 复制工件插件中有一个新的(我认为)工具,您可以从该版本号中指定构建号和您想要的工件
    • @xeraa :你有解决这个问题的办法吗?我面临同样的问题。提升构建 #60,然后尝试提升较小版本是提升工件的最后一个提升版本。
    • 很遗憾没有。最后的构建总是“赢”
    【解决方案3】:

    顺便说一句,您可能会发现Workflow system 可以更轻松地自定义这种管道逻辑,而根本不需要使用Promoted Builds 或Copy Artifact 插件。

    【讨论】:

    • 如果可能,您能否描述一下如何使用管道而不是复制工件?我们有一个多阶段管道,每个阶段都在一个新的 kubernetes pod 中运行,我想访问在前一个阶段构建的存档以进行集成测试。除了存档工件(或发布+下载到其他位置)之外,我可以在我的管道中做些什么特别的事情来共享在早期阶段专门构建的工件?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-28
    • 1970-01-01
    • 2015-01-10
    • 1970-01-01
    • 2021-11-03
    • 1970-01-01
    相关资源
    最近更新 更多