Github Organization Folder PluginがJenkinsfileを見つけられませんか？

Github Organization Folder Pluginを使用するためにJenkinsfileを取得する際に問題が発生しました。リポジトリをスキャンするとき、プルリクエストをチェックするときにJenkinsfileを見つけることができないと言います。リモートブランチをチェックすると、Jenkinsfileが見つかります。ここでGithub Organization Folder PluginがJenkinsfileを見つけられませんか？

が出力されます。

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)

私はトラブル理解がリモートプル要求とリモートブランチとの間の差であるが何をしています。また、ブランチではどのようにそれを見つけることができますが、プルリクエストではありませんか？

ありがとうございました！

EDIT

：私は2つのプル要求がまだJenkinsfile自分自身を持っていないと仮定し Results

出典

2017-05-16 Jonathan Wong

プルリクエストを検出していますが、プッシュリクエストには触れないことに注意してください。ジェンキンスさんは、他の人のリポジトリへの読み取り/書き込みアクセスを参照する権限を持っていない場合、これはまた起こることができることを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.

注：これは、ここで説明したセキュリティの事です！

リモートプルリクエストとリモートブランチの「リモート」とは、「ローカルgitの履歴を調べずに、SCMにあるプルリクエストとブランチを検索する」という意味です。 Jenkinsの違いは、リモートブランチのJenkinsファイルは常に信頼されるということですが、上記の要件が満たされない限り、PRは信頼されません。

出典

2017-05-17 13:21:42

それは非常に興味深いです、私はそれを見てみましょう。ありがとう！ –

私は問題を抱えている理由は、私がプッシュを行うことが承認されていないということです。私のアカウントには読み書きアクセス権がありますが、私が実際に書く前にプルリクエストを承認する必要があります。このための回避策はありますか？ –

空のJenkinsfileがマージされた場合は、PRを再度開いて、Jenkinsのビルドで "再生"をクリックしてトリガされるように作業を開始できます。空の入力ボックスが表示され、そこでJenkinsfileが進行中であることを示すことができます。これは次のようになります。https://jenkins.io/doc/book/resources/pipeline/replay-modified.png Jenkinsfileの動作を確認してからマージすると、今後の人々からのPR/o書き込みアクセスは、ターゲットブランチのJenkinsfileに "フォールバック"します。現在作業していない理由は、あなたのターゲットブランチにJenkinsfileがありません。 –

：ここは、スキャンの結果です。

Jenkinsfileを追加したブランチが1つあり、Jenkinsfileが正しく検出されます。名前はJenkinsfileの最初のブランチのように見えます。そのため、他のプルリクエストにJenkinsfileがまだないと思われる理由です。

Jenkinsfileはブランチごとです。すべてのブランチに対して有効な "メイン"/"マスター" Jenkinsfileはありません。あなたのマスターブランチがJenkinsfileを持っているとすぐに、それ以上のブランチもそれを持っていて、あなたが期待どおりにすべてが動作します。

出典

2017-05-17 08:52:26

返信いただきありがとうございます！＃55は、私がマスターにマージしようとしているadd_jenkinsfileブランチです。プルリクエスト＃57には、Jenkinsfileと同じJenkinsfileも含まれていますが、ブランチに問題があると思ってコピーしました。別の注意、私は結果が2つの枝を示すようにJenkinsfileを持っている他のブランチについてはスキャン結果が言及していないことに気付きました。質問をスクリーンショットで更新します。 –

Github Organization Folder PluginがJenkinsfileを見つけられませんか？

答えて

関連する問題