Amend creates new commit number and triggers abort, but doesn't start new run.
Version Details
Jenkins version: 2.7.4 Integration Plugin version: 0.1.0-rc29
- Search for existing github issue = no matching issue found
Issue Details
Issue:
A user has a commit they push and create a PR, which and via webhook trigger (set to PR Opened / Commit Changed), our jobs start.
The user runs a git --amend command, which changes the commit sha, and the webhook triggers a "Newer PR forthcoming", aborting the current job. However, the --amend doesn't seem to trigger the "Commit Changed" triggers for the PR Github Integration, and no jobs start.
Github PR Polling Log:
It overwrote once I refreshed, but when I just looked the link did say "ERROR: Cannot finish trigger check"
Was it force push?
I believe so, yes.
[image: Udemy.com] Scott Estes Build Engineering [image: Email Me] [email protected]
On Mon, Apr 23, 2018 at 2:24 PM, Kanstantsin Shautsou < [email protected]> wrote:
Was it force push?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KostyaSha/github-integration-plugin/issues/267#issuecomment-383728040, or mute the thread https://github.com/notifications/unsubscribe-auth/AVH6AgxvJt9Ff31x9dDwhG5gcwyrLhEkks5trkaAgaJpZM4Tgnf8 .
need compare github API information about PR/issue before and after
Ok, so far we look to not be triggering on Amend, Merge Master, Rebase Master, but this also seems to be dependant on sequence (for example, --amend --date didn't (--force used), but merge master did (no force). We can successfully make the runs fire with an Empty commit if required, but would prefer not to push empty's if possible.
The easiest repro I had was:
- push commit
- create pr (ci starts after webhook)
- push --amend --date --force (no ci runs)
Can you explain what you mean by compare github API information about PR/issue before and after? Are you thinking the regression may be on the github API side?
Trigger uses github api to track critical for triggering data (hash, time, etc. depends on what "events" are choosen) https://developer.github.com/v3/pulls/#get-a-single-pull-request somebody need to check pick API answer before force and after and compare what changed or what doesn't.
I did a comparison of the pull request object before and after the issue occurred, and did not see any discrepancies in the raw_output that was returned. The only data that changed was "pushed at" and "size" which is expected.
Could it be on the hook side itself? When using the Github webhook approach instead of polling, what do we use from the webhook payload to determine triggering? In Jenkins I have set PR Opened and Commit Changed. Even though a new commit shows up in Github under the PR, we still have instances where CI is not being triggered. The only thing that looked new to me was an action of "synchronize", which I didn't recognize. From the event type API wiki, this was interesting.
While webhooks are also triggered when a pull request is synchronized, Events API timelines don't include pull request events with the "synchronize" action.
My webhook Fires for Pull Requests and Push Events, should any more be added to ensure all triggers will fire?
One issue on my side I think was that I didn't have the "Not Mergeable" Trigger set as that is new to us compared to the version of the Plugin we were previously using. That looks to have fixed some of the misses, but I just hit an instance where the user pushed a new commit and nothing triggered still.
The one interesting item I saw there is we are using the the codeowners logic which auto-generates a review request to the owning team of the specific code. Looking at the webhook though, this is still seen as a "review requested" which should be included under the Pull Request Triggers.
Plugin is not handling (not starting check) on review request changes (that should be separate "event").
ok. Then for the short term I've updated to use the webhook with Cron as well, using the CRON to catch any extras that aren't triggering with the current Webhook logic.
Is this a fix that can be included in the development iteration?