-
Notifications
You must be signed in to change notification settings - Fork 140
Trouble with pattern match from examples #30
Comments
@orangejulius please see the faq which has a few different items for troubleshooting https://lgtm.co/docs/faq/ ... specifically checking the LGTM response to the GitHub hook. That should provide additional information for debugging. Note also that LGTM can be considered deterministic with the exception that makes API calls to GitHub. So I would not expect inconsistent behavior unless there were issues interacting with GitHub. If this is the case it would likely be reported in the response. Note that I also recommend digging into the source code as well. This is the best way to debug as I generally only provide high level support for this project due to time constraints. note: edited my reply because it wasn't super polite, sorry about that. Feeling some serious open source burnout at the moment |
Hey, no worries, I understand all about being busy. I'm sorry my comment made it look like I just wanted free support. I care much less about that than helping get a possible bug fixed for everyone. Anyways I dug into the webhook responses for pelias/whosonfirst#105 since they are still available. I included a quick summary of events and then the full webhook bodies (I think only a small part of the body is relevant but this way there's no possibility of missing something). quick summary of the flow in the PR
The comments were spaced out by at least several minutes, and not edited, so I'm not sue what could be going on. The response code for all of them was 200 and the .lgtm file is a month old, much older than the PR, so I think all the bases are covered and that this really may be a bug. If there's something I missed I'm happy to check it out though. I will try to look into the source in the near future if I have the time but if you have any ideas of where to look it would probably help speed things up. First comment request body
first comment webhook response
Second comment webhook request
Second comment webhook response
Third comment webhook request
Third comment webhook response
|
sorry about that. I had edited the above comment with an apology. I've been feeling major open source burnout this weekend. No excuse though for me not being polite.
if this happens again can you do me a favor and re-submit the hook from the GitHub user interface? LGTM pulls the full list of comments from GitHub and ignores the payload it receives. Maybe GitHub serves some API calls from an eventually consistent cache? I think it would also make sense to return the list of comments with a match true / false to simplify this sort of debugging, something like:
|
Hey @bradrydzewski, I have a new PR that can serve as an example of things breaking: pelias/documentation#132 I tried resubmitting the webhook a couple times several minutes after the last comment went in, but there was no effect. How else can I help you debug this? |
@orangejulius sorry for delayed reply. I'm planning on jumping back in the LGTM code next week since GitHub is introducing breaking changes to their API and LGTM needs updated. While I'm in the code I'm planning to alter the payload response and echo back the list of comments including whether or not the comment matched (true / false). Hopefully this will help shed some light. Hang in there and I'll hopefully have an update for you mid-week. Thanks! |
Hello,
We've been using LGTM with the Pelias project for a few weeks, and overall it's been a nice way to handle signoff on our PRs, so thank you.
There's one thing we can't figure out though: we put
, but not 👍. We can't figure out why this is, and have tried to eliminate all the possibilities.
pattern = "(?i):shipit:|:\\+1:|LGTM"
in our .lgtm file as shown in the customization docs, and it works great for registering comments with LGTM andExample PRs
Working with
or LGTM
First, an example pull request where everything worked great. Both reviewers responded with
, and as you can see in the merge details, the LGTM check passed. You can see the .lgtm file is also a direct copy of the config example from the docs. Comments with LGTM(although I can't find an example PR) or a combination of the two work fine too.
Broken with 2 👍's
In another pull request, both reviewers responded with 👍, and the check failed. It's a little hard to see in the pull request itself, but it only lists our two travis checks as passing. If you find the PR in the list of closed PRs, and hover your cursor over the yellow circle, you'll see there was a 3rd check that failed, the LGTM one. It's a different repo but the .lgtm file is exactly the same.
![screenshot_2016-07-10_17-56-28](https://cloud.githubusercontent.com/assets/111716/16716345/c9568e06-46c7-11e6-8f48-b5267769e9a1.png)
Sometimes broken with 👍 and LGTM or![:shipit: :shipit:](https://github.githubassets.com/images/icons/emoji/shipit.png)
This is the weirdest one. Here's an example where it works, and another where it doesn't.
The regex seems to work
The weird thing is the regex from the docs seems to work in the Go Playground, so I'm not sure where the problem is. I'm happy to paste info from webhook calls if that helps, or make any other config changes to our repos you'd like to test things out. Any ideas?
The text was updated successfully, but these errors were encountered: