Question

我一直遇到让Jenkins文件与Github Organization Folder Plugin一起使用的问题。扫描存储库时，它表示在检查拉取请求时找不到Jenkins文件。当它检查远程分支时，它可以找到Jenkins文件。

这是输出：

 Getting remote pull requests...

    Checking pull request #57
    (not from a trusted source)
    Job name: PR-57
      ‘Jenkinsfile’ not found
    Does not meet criteria

    Checking pull request #55
    (not from a trusted source)
    Job name: PR-55
      ‘Jenkinsfile’ not found
    Does not meet criteria

  2 pull requests were processed

  Getting remote branches...

    Checking branch add_jenkinsfile
      ‘Jenkinsfile’ found
    Met criteria

  0 branches were processed (query completed)

我理解的是远程拉取请求和远程分支之间的区别。它怎么能在分支中找到它而不是拉取请求？

感谢您的帮助！

编辑：以下是扫描结果： Results

Answer 1

请注意，它会找到拉取请求，但拒绝触摸它们。这是一个安全事项：https://support.cloudbees.com/hc/en-us/articles/227246367-Why-Jenkinsfile-changes-Are-Not-Reflected-in-PR-Build

This is due to the fact the author of the Pull Request is not trusted. In that case Jenkins falls back to the Jenkinsfile of the base branch.

Changing the Jenkinsfile is equivalent to changing the job configuration. Only users with a certain level of trust should be allowed to do it.

Jenkins handles it that way: when changes to the Jenkinsfile are committed to a PR , Jenkins asks GitHub whether the PR author has the permission to push to the origin repository, if yes he is trusted, otherwise he is not.

请注意，如果Jenkins没有权限查看其他人对存储库的读/写权限，也会发生这种情况！

＆＃34;遥控器＆＃34;在远程拉取请求和远程分支中只是意味着搜索位于SCM上的拉取请求和分支，而不是查看任何本地git历史记录＆＃34;。詹金斯的不同之处在于偏远的分支机构。 Jenkinsfiles永远是值得信赖的，但除非满足上述要求，否则不会信任PR。

Answer 2

我认为两个拉取请求本身还没有Jenkins文件。

你有一个分支，你添加了一个Jenkins文件，所以检测到一个很好。这个名称看起来像是你的第一个带有Jenkins文件的分支，这就是为什么我假设你的其他拉取请求还没有Jenkins文件。

Jenkinsfile是per-branch。没有“主”/“主”Jenkins文件对每个分支都有效。一旦你的主分支有一个Jenkins文件，进一步的分支也会有它，一切都会按预期工作。

Github Organization Folder Plugin找不到Jenkinsfile？

2 个答案: