jhohertz
commented
3 years ago I have finally had a chance to trace this down. It was insidious, and ended up being a case handling thing.
GitHub is generally case-insensitive regarding names, and the difference between where it worked and did not, ended up being which had correctly expressed it, ignoring also a "Display Name" that used the opposite capitalisation, which confused matters a little. Once I saw this through building a version of the plugin w/ some additional logging, the variation in configuration was identified.
This case sensitivity seems to be unique to this plugin. Everything else about the installation (github source branch, the new github checks / warnings stuff) all worked fine. This is the only plugin with an issue.
It seems to be where the key is looked up in the trigger vs. how it was stored that the misalignment occurs. Perhaps by storing and comparing lowercase representations would help make it less picky about this.
If someone from the project could confirm this would be acceptable I would be happy to work out a PR at some point.
It's not a critical thing. The case just needs to be exact in source branch config. But it would be more consistent w/ other plugins to address this.
aaronwalker
Background: I am building out a new pipeline-library+github org w/ source branch plugin setup to migrate to... from a ghprb+manual pipeline jobs setup. The former has been developed in isolation of our Jenkins setup, and when bringing it over to our main Jenkins installation, for some reason the issueCommentTrigger silently fails to work.
I had initially suspected that somehow the ghprb plugin was getting in the way and "eating" the hook trigger, but that doesn't seem to be the case for a few reasons. First it doesn't make sense to me as they use different hook endpoints (ghprb having it's own, everything else using /github-webhook). Secondly, I have been adding ghprb and other plugins unique to the existing Jenkins instance to the test, trying to reproduce the problem, but have thus far been unable to reproduce it.
A little lost on what's happening, going to see if somehow plugin load order is a thing, and could explain this difference in experience next, but thought I would reach out in case anyone else has experienced a similar problem with issueCommentTrigger, or had suggestions on how to debug the flow of hooks into triggers.
EDIT: Just also wanted to add, I do see the trigger in the job's config.xml after the pipeline has run on that instance, so AFAIK the plugin is doing the right thing in registering the trigger. I just don't see it fire. Also, the rest of the new org-based repos seems to work fine, sees PRs, updates to them, acts on them. Just the comments get lost.
EDIT: Also will mention I have been through #10 and none of it quite applies here I think... though there are some common themes.