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.
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
Unfortunately, it doesn't seem that there is any way to disable it. Otherwise, I would just do that.
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.
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).
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.
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.)
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.
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.
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:
"ci_cd_only": true
).GH_TOKEN
variable (in project level variables).coqbot
webhook.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!
Done: https://github.com/coq/bot/issues/127.
Last updated: Sep 28 2023 at 11:01 UTC