时间戳

首页 > 解决方案 > 与master相比，如何根据更改的文件来防止作业运行？

gitlab - 与master相比，如何根据更改的文件来防止作业运行？

问题描述

我的管道中有一些 gitlab 工作很慢，我想在更改不会影响工作结果时阻止它们运行。

这是我尝试过的：

run_tests:
  stage: checks
  script:
    - cargo test
  except:
    - master
    - tags
  only:
    changes:
      - "**/*.rs"
      - "**/Cargo.toml"
      - "**/Cargo.lock"

这类作品。如果一个合并请求有多个提交，这个作业将不会在第一个之后的任何提交上运行，除非 Rust 源文件已更改。

但该作业仍将始终在分支的第一次提交时运行，即使此分支和 master 之间的 Rust 源文件没有更改。更糟糕的是，如果测试在第一次提交时失败，后续提交可能会跳过测试，因此损坏的代码可能会被合并。

如何更改此过滤器，以便针对合并请求的目标分支完成差异？

标签： gitlabgitlab-ci

解决方案

在文档中隐藏得很深only: changes，有这个片段：

如果没有用于合并请求的管道，则管道在与合并请求没有显式关联的分支或标签上运行。在这种情况下，之前的 SHA 用于计算 diff，相当于 git diff HEAD~。这可能会导致一些意外行为，包括：

  • 将新分支或新标签推送到 GitLab 时，策略始终评估为 true。
  • 推送新提交时，更改的文件使用先前的提交作为基本 SHA 计算

这是您当前遇到的情况，作业总是在新分支的第一次提交时运行。

为此，我相信您需要添加only: merge_requests，但这需要更改整个管道工作流程以集成only: merge_requests到您的管道中。

从文档中：

使用合并请求的管道，可以根据合并请求中修改的文件定义要创建的作业。

为了推导出源分支的正确基本 SHA，我们建议仅将此关键字与：[merge_requests] 组合。这样，文件差异可以从任何进一步的提交中正确计算，因此合并请求中的所有更改都在管道中正确测试。

来自 GitLab 的各种问题：

推荐阅读