[
https://issues.apache.org/jira/browse/YETUS-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211813#comment-17211813
]
Allen Wittenauer commented on YETUS-1022:
-----------------------------------------
Started playing more with GitHub App support on Jenkins today. Branches
appeared to be working fine after re-configuring the Jenkinsfile to point to
the GitHub App token rather than the PAT I was using. Statuses still failed,
which was a bit unexpected. Digging into further I discovered that:
* Jenkins GIT_COMMIT variable was pointed to something that didn't match GitHub
* GitHub API was (correctly) returning a 422
422 was a HUGE clue as to what was going on. It's not a "permission denied"
error: it is a "what was passed was formatted correctly and are allowed to do
that, but what was sent was non-sensical." Looking at what test-patch sent and
what was in the repo, it became clear that test-patch was trying to give status
on a sha that didn't exist in github's view of that repo.
> Get commit sha from github PR json
> ----------------------------------
>
> Key: YETUS-1022
> URL: https://issues.apache.org/jira/browse/YETUS-1022
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
> Reporter: Allen Wittenauer
> Assignee: Allen Wittenauer
> Priority: Major
> Fix For: 0.13.0
>
>
> For some CI systems (Jenkins), the merge strategy sets the commit sha to the
> local sha, not the one in GitHub. github plug-in should probably always
> override our internal variable if we've been given a github PR number.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
