Hi, we've tried to use the instructions at https://github.com/coq/bot/#how-to-use-the-coqbot-instance to deploy coqbot across our GitHub org (https://github.com/saltstack-formulas). So far, coqbot only shows up for PRs that are made using branches from the parent repository (non-forked), which GitLab can already handle. E.g. https://github.com/saltstack-formulas/test-formula/pull/2/checks (whereas PR #1 sent from a fork didn't work). What steps are available to troubleshoot this further?
@Théo Zimmermann please move this post to the coqbot stream
This topic was moved here from #Miscellaneous > How to troubleshoot coqbot? by Théo Zimmermann
Enrico Tassi said:
Théo Zimmermann please move this post to the coqbot stream
Ah, sorry. This stream didn't show up on the left-hand side by default. Thanks for moving it.
I've tried various combinations (of GitHub/GitLab repos and repo paths) with the bot; is there any advantage of using the legacy method (as a regular user account)? I've added it to one repo but currently at Awaiting coqbot’s response
-- any idea how long this will take before the invitation is accepted?
OK, the invitation has just been accepted; now to continue testing...
Dear @Imran Iqbal, with the legacy method, I have to manually validate the invitation. I've just done that.
I'm available to help you debug your setup now.
Théo Zimmermann said:
Dear Imran Iqbal, with the legacy method, I have to manually validate the invitation. I've just done that.
Thanks for that. Is it a more stable method to use?
In principle, both should work well. Both are currently in use across various organizations.
OK, I just force-pushed a PR and I can see the outgoing webhook was successful (200
). No pipeline in GitLab yet.
If I understand correctly, you've first tried the GitHub App method?
Yes, I tried the app method first.
Can you give me a link to a PR from a fork for which it didn't work?
coqbot
would be displayed if the PR branch was from the parent repo itself (which GitLab handles anyway) -- I couldn't get it involved with a forked repo... OK, https://github.com/saltstack-formulas/test-formula/pull/4.
^ The force-push I just did sent the outgoing webhook fine from GitHub. Nothing received in GitLab, though (checked webhook there).
I've simplified the GitLab end by matching it up with the GitHub side (https://gitlab.com/saltstack-formulas/test-formula).
Originally tried the repo in the place we wanted it and set the coqbot.toml
as mentioned in the README. Thought I'd remove that configuration and just get it working in the basic way first.
I've got something weird in the logs. It might be a bug. I'll need to investigate more.
@Théo Zimmermann OK, shall I check back in an hour or so?
Can you confirm first that you didn't forget to give coqbot access to your GitLab repo?
Absolutely gave it, with Developer
permissions:
coqbot @coqbot
Given access 1 hour ago
OK. I'll look into this more. I'll ping you when I get more info.
Thanks, I appreciate it.
I've identified a first problem linked to the mapping:
https://github.com/saltstack-formulas/test-formula/blob/398a4165f4bd5544d0e2a2b53939b085b60743de/coqbot.toml
The current implementation is unfortunately expecting a repository in the form owner/name
.
If you look, I've removed that file and gone to a basic setup without the coqbot.toml
file.
I've even moved the repository in the GitLab side to match the GitHub side.
@Théo Zimmermann Is this enough or would I have to set up another test repo with owner/name
right from the beginning?
It should be fine.
So what's the next step I can take?
I guess you also disabled the GitHub App.
Yes, so that I could try the account method instead. I tried the GitHub App with the coqbot.toml
removed as well.
(And the repo paths matching on both sides).
OK
OK, I've found what the issue was.
Excellent! So there's hope...?
Yes, you should see that there are new status checks on https://github.com/saltstack-formulas/test-formula/pull/4
Checking...
So basically, the main issue was the one I've already explained.
The owner/repo
issue?
Yes. And the second issue was that the data was not updated when you removed the file.
So basically, I've restarted the bot to remove the data from memory.
OK, there's one other repo where I configured coqbot.toml
-- will that work OK if I change it now?
Yes, it should.
So would it be better if I go back to using the GitHub App instead? We're planning to use this across ~100 repos in our org.
Yes, definitely.
Both easier to setup and you get more features.
Excellent, I'm going to try some stuff out now and I'll get back to you if there are any issues. Really appreciate the help!
Would you mind opening two issues on the bot's repository to remind me of fixing the two we found out?
That way, you'll also be informed when I fix them.
What was the second issue?
That the modification to the coqbot.toml
file was not taken into account.
Ah, OK -- I'll do that shortly.
Thanks!
BTW, there was another difference I noticed when following the instructions:
The bot will only take care of mirroring the PRs and reporting status checks back so you may still want to activate the mirroring feature for the main branches. To do so, the easiest way is to choose the "CI/CD for external repo" option when creating the GitLab repository. However, you should opt to give the repo by URL rather than with the GitHub button, because we won't need GitLab's own status check reporting feature. (If it is already activated, you can disable this integration in the "Settings" / "Integration" menu).
Oh! That's interesting!
The sync itself still works but I had to manually trigger it each time.
I've heard from another user (@Erik Martin-Dorel) that had the same problem.
And specifically this part:
(If it is already activated, you can disable this integration in the "Settings" / "Integration" menu)
This is a GitLab bug but it can't be disabled if it's already set up!
Would this even be a problem if we did use the GitHub button instead of giving the repo by URL?
Would this even be a problem if we did use the GitHub button instead of giving the repo by URL?
You would get duplicated status reported to your GitHub repo.
(one by GitLab and one by coqbot)
Oh dear, the merge commit performed by coqbot
is affecting our commitlint
check: https://gitlab.com/saltstack-formulas/test-formula/-/jobs/907388641#L34.
[CI merge] PR #5: docs(readme): make minor adjustment to test PR GitLab pipeline (from fork)
The merge commit is a great idea, since it behaves like Travis, etc.
Now I'm going to have to figure out how to ignore that particular commit and check the commits from the PR instead...
Théo Zimmermann said:
Would this even be a problem if we did use the GitHub button instead of giving the repo by URL?
You would get duplicated status reported to your GitHub repo.
Now that I think about it, you wouldn't get duplicated status reported to your PRs, only to your branches. (Because of these merge commits.)
OK, I may just try setting up the CICD links in the usual way and see how that affects things.
BTW, I've gone back to using the GitHub App and it appears to be working fine!
Cool!
OK, let me add those two issues that you mentioned...
Thanks!
@Théo Zimmermann Thanks for helping out earlier, we've got coqbot
configured for ~95 repos and it seems to be working really well -- we got caught out badly by https://gitlab.com/gitlab-org/gitlab/-/issues/5667 (which is where we heard about coqbot
as a potential workaround).
A couple of questions:
@coqbot
, such as restarting the pipeline or individual jobs?saltstack-formulas/formulas/github/saltstack-formulas/test-formula
instead of saltstack-formulas/test-formula
). Would be glad to test any developmental efforts.@Imran Iqbal Regarding 1., since you've installed with the GitHub App in the end, you should see "Re-run" buttons on failed jobs and pipelines. I've just opened a PR updating the doc. See https://github.com/coq/bot/pull/122. More specifically, see https://github.com/Zimmi48/bot/blob/document-re-run/README.md#github-checks-features.
Thanks, I'll check that out.
Théo Zimmermann said:
Imran Iqbal Regarding 1., since you've installed with the GitHub App in the end, you should see "Re-run" buttons on failed jobs and pipelines. I've just opened a PR updating the doc. See https://github.com/coq/bot/pull/122. More specifically, see https://github.com/Zimmi48/bot/blob/document-re-run/README.md#github-checks-features.
This would be good if it could be set for other repos as well; we have this problem quite often: https://github.com/Zimmi48/bot/blob/document-re-run/README.md#post-comment-when-a-pull-request-does-not-respect-certain-standards.
Do you wish for the same exact comment or for a configurable message?
Regarding 2., I've just pushed a fix. I'm pretty confident it will work, but you need to wait for deployment to be complete before you can test it.
Even the same comment would be useful for the time being. Ultimately, end users would prefer to be able to customise that to their needs. Probably in the coqbot.toml
, right?
Right.
Théo Zimmermann said:
Regarding 2., I've just pushed a fix. I'm pretty confident it will work, but you need to wait for deployment to be complete before you can test it.
Great! Please ping me when it's ready to test.
You can check this: https://github.com/coq/bot/runs/1572857089. It should be a few minutes.
Sure; I've got a test repo set up already.
Great!
Can you open an issue about the comment feature so that I don't forget?
Sure, I'll do that soon, just juggling a couple of things at the minute...
Théo Zimmermann said:
You can check this: https://github.com/coq/bot/runs/1572857089. It should be a few minutes.
Interesting! It's definitely working, the pipeline has been triggered from the PR that is introducing coqbot.toml
(without it even being in the master
branch just yet). The integration isn't showing up in the PR but that will probably work once coqbot.toml
is available in the master
branch.
Yes! A second PR after coqbot.toml
is in the master
branch has resulted in the coqbot
integration working. I've got other issues now with pre-commit
but that doesn't appear to have anything to do with this change. Looks like all is working well!
Can you give me a link to the first PR? I'm surprised by what you describe.
I was expecting only the configuration file in the default branch to have an effect.
Sure: https://github.com/saltstack-formulas/test-formula/pull/9
This was the pipeline that was triggered by that PR: https://gitlab.com/saltstack-formulas/formulas/github/saltstack-formulas/test-formula/-/pipelines/231565413.
OK the explanation for the first PR is simply that GitLab has created a redirection from https://gitlab.com/saltstack-formulas/test-formula to https://gitlab.com/saltstack-formulas/formulas/github/saltstack-formulas/test-formula.
Right, so if I hadn't moved the repo, it probably wouldn't have worked.
So new repos under that namespace wouldn't work until the coqbot.toml
is available.
Yes, that's what I would expect.
Ah, my pre-commit
problem was due to caching, so that's fixed as well. I'll probably take the chance and move our repos over. Or perhaps I'll just create them fresh, to avoid the redirects. Thanks again!
FYI after checking the log, there might still be remaining issues. Please do not move all your repositories to the new location just yet and be ready to report any issue you notice in practice to me.
Any specific checks you want me to make on the test repo? There won't be much more activity other than there, since I won't be moving any of the other repos over after what you've just mentioned.
OK so the issue is actually related to something I've already discussed with my intern this summer and had ask him to open an issue about but I don't think he did.
Basically, we store a correspondence table between GitHub and GitLab repository.
When we are called on a GitHub repo, we can check the coqbot.toml file in the default branch if we don't know the correspondence yet.
Right.
But when we are called on a GitLab repo, we don't have a fallback other than trying the same full name on the GitHub side if we don't have the correspondence in store.
There are two consequences of this:
when you move your repository to the new location
Would the same happen if I recreated the repo in the new location, instead of moving it?
No because there would be no remaining status checks.
The second consequence is possibly more problematic.
And that wouldn't happen with the default repo location?
No, because that would be the fallback location if there is nothing in the correspondence table.
I don't know how much it would be an actual problem in practice though.
Gotcha.
But anyway, there is a clear fix which is to load all the config files for all the repositories where the bot is installed when it restarts.
Yes, that sounds appropriate. I'll be available for further testing if you need me!
I'll try to find some time to implement it during the Christmas holidays.
Thanks again for your feedback (and don't forget about opening the issue we talked about earlier today).
Of course, whenever that's available. We're good for the time being. Thanks for your help. I'll get around to adding that other issue soon.
Still juggling!
Perfect, thanks!
No problem. Bye for now.
Last updated: May 28 2023 at 18:29 UTC