I have a GitLab account where we have many of our repositories stored inside of groups that are inside of groups. For example, we use the following structure on GitLab.
Group A > Group B > Repository
In this example, Group A is our company name, and Group B is a team internally with a handful of projects.
This seems to cause issue? At least, I seem to have a bunch of GitLab issues that seem to maybe be influenced by this, for example:
-
When I go to add a new app and import with GitLab (my account is setup fine I believe?), Bitrise always fails after the “Loading provider info, hang tight for a sec…” step, with an error of “Failed to load provider info!”. So I’ve had to manually set up all of my projects with a Gitlab clone URL so far.
-
After any successful build, on the top of the build page, I see this error: “Unable to send build status back to GitLab. Please check our webhook troubleshooting guide.”
-
When I click the Source button on the top right of the Project page, (with Gitlab logo, next to Watch button), the corresponding URL gives me a 404 back on GitLab. When I look at the URL path in the browser, it seems to be the right URL, but it’s missing the Group A part of the url path (with example above). So for example, whereas the proper project URL should be https://gitlab.com/group_a/group_b/repository, the Source button links to https://gitlab.com/group_b/repository. This is kinda what lead me to think that the groups inside of groups are what are causing the issue.
1 Like
Another quick note, see this also while setting up a project, during the Webhook Setup stage:
“Failed to register webhook. Make sure that you have the required access rights to the repository!”
1 Like
Thanks for reporting @CameronBanga!
We’ll debug this ASAP! In theory this should definitely work (except maybe the last point, the “Source” button), but we’ll look into this and let you know what we find (and fix the issues of course)!
Thanks for the detailed description of the issue, @CameronBanga! We were able to reproduce it by adding a GitLab repo “manually” (via clone URL). You were right, it was related to how GitLab subgroups are getting handled on our side.
We’ve deployed a fix, so newly added apps won’t be affected. For existing apps though like yours, an admin should reset the repository’s URL on the App Settings page (by changing the URL to something else, saving it, then changing it back.) Sorry for the inconvenience!
After resetting the URL, build status messages should be sent back to GitLab successfully, and the Source button should point to the right URL.
Let us know if it helped!
PS. We were not able to reproduce the GitLab connection issue, subgroups were loaded successfully after connecting a GitLab account to Bitrise. Please try to reconnect your GitLab account on your Bitrise profile page and let us know if the repositories are still not loading.
1 Like
Testing but this looks to be working great! Thanks so much guys.
Tried disconnecting and reconnecting my GitLab account, but still seeing the issue where repositories aren’t loading. If there’s anything I can do to help/debug, let me know!
@CameronBanga can it be that you have a large amount of repos on GitLab?
This error usually happens if there’s a timeout, when GitLab does not respond with the list of repos / groups.
Oh yeah, I have a ton of repos. Over 200 something I think.
Can see that and thought it may be issue. Never had the issue with BuddyBuild though. But good to know, I can keep using manual for now.
1 Like
Got it - created an internal bug report, thanks for the details! 
