Stream: coqbot devs & users

Topic: coqbot starts creating empty, unconfigured repositories


view this post on Zulip Imran Iqbal (Feb 05 2021 at 09:04):

Just ran into a side effect of adding @coqbot as a developer on our GitLab organisation. It starts creating empty, unconfigured repos where there is activity in GitHub but a mirror isn't available in GitLab. For example:

Ah, just realised that you won't be able to see those, since @coqbot created them with private access only! That's probably the default setting in GitLab. Anyway, I've configured the first one so that it is publicly visible.

Now if this created the repos with the actual necessary settings, such as with the GitHub mirroring configured, this would be a fantastic feature! But in reality, we'd like to create this repos ourselves, when needed. With the GitLab repo already present, my script using GitLab's API to create the mirrored repo failed:

{
  "errors": "Name has already been taken, Path has already been taken"
}

So I have to manually delete these repos before being able to create them again.

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 16:49):

It looks like this is because of this (unwanted and little known) feature: https://docs.gitlab.com/ee/gitlab-basics/create-project.html#push-to-create-a-new-project

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 16:49):

Unfortunately, it doesn't seem that there is any way to disable it. Otherwise, I would just do that.

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 16:51):

Note that currently, it is expected that all the repositories on which the GitLab App is installed want the GitLab sync feature. You can choose to install a GitLab App on a subset of repositories owned by an organization, though that could be tedious if you want to install it on almost all repositories.

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 16:53):

It seems to me that the long-term solution to this is to not automatically sync with GitLab unless explicitly opted-in through a setting in coqbot.toml (at least for users who have installed coqbot using the GitHub App).

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 16:55):

Also, feel free to open an issue about the ideal auto-creation of repository feature. Using the API instead of just a git push command should allow to set all the parameters properly and should be relatively easy to implement.

view this post on Zulip Théo Zimmermann (Feb 05 2021 at 16:56):

I don't want to make any promises regarding an ETA though because I'm a bit swamped these days and I have had little time to allocate to coqbot development. (It should be better in a couple of months but I can't say what time I will find for this before then.)

view this post on Zulip Imran Iqbal (Feb 06 2021 at 10:52):

Théo Zimmermann said:

Note that currently, it is expected that all the repositories on which the GitLab App is installed want the GitLab sync feature. You can choose to install a GitLab App on a subset of repositories owned by an organization, though that could be tedious if you want to install it on almost all repositories.

Yes, I'd expect this would work in most cases. Unfortunately for us, neither option would work too well. We've got 350 repositories but only ~100 have proper CI configuration available. So we'll just have to bear with it; it's only a minor inconvenience, really.

view this post on Zulip Imran Iqbal (Feb 06 2021 at 10:52):

Théo Zimmermann said:

It seems to me that the long-term solution to this is to not automatically sync with GitLab unless explicitly opted-in through a setting in coqbot.toml (at least for users who have installed coqbot using the GitHub App).

This sounds like a realistic resolution for the longer-term.

view this post on Zulip Imran Iqbal (Feb 06 2021 at 10:57):

Théo Zimmermann said:

Also, feel free to open an issue about the ideal auto-creation of repository feature. Using the API instead of just a git push command should allow to set all the parameters properly and should be relatively easy to implement.

Sure, I should send this situation through in an issue anyway. As for the API bit, this may be a little tricky, since I'm sure each organisation will have their own customisations they'd want to perform. For us, we use our API script to do the following steps:

  1. Setup GitLab CI/CD for external repositories (specifically setting "ci_cd_only": true).
  2. Setup GH_TOKEN variable (in project level variables).
  3. Setup coqbot webhook.
  4. Setup Zulip webhook (we push our GitLab CI pipeline data to our own Zulip instance, for a central place to see everything).

view this post on Zulip Imran Iqbal (Feb 06 2021 at 10:58):

Théo Zimmermann said:

I don't want to make any promises regarding an ETA though because I'm a bit swamped these days and I have had little time to allocate to coqbot development. (It should be better in a couple of months but I can't say what time I will find for this before then.)

Completely understand. Thanks for taking the time to reply!

view this post on Zulip Imran Iqbal (Feb 06 2021 at 11:05):

Done: https://github.com/coq/bot/issues/127.


Last updated: May 28 2023 at 18:29 UTC