P3
When configuring a new repository in Gitlab (typically forking jdk mainline to a release repository like jdk17), our labels aren't automatically propagated to the new repository.
The way labels work in Gitlab and Github is different. On github, we have the skara /label command to manually add labels. In Gitlab, this command is native, so is not handled by Skara at all. This difference is causing some different semantics when trying to add a new label for the first time in a particular repository. Gitlab will only let the /label command add labels that are preconfigured for the repository. On Github, because Skara is running the /label command, it seems that when adding a label through the rest api, it's automatically added to the repository. The only way new labels are added to repositories in Gitlab today is when Skara automatically matches code changes in a PR to a label, in which case Gitlab seem to accept new labels and add them to the repo if needed. What this means in practice is that users can't manually add a label until another PR has been created which automatically added that label.
Unfortunately, Gitlab does not provide any way to bulk import labels when we create a new fork. That would otherwise have been a convenient way to handle this.
I think we need to add some logic somewhere that syncs the label configuration from Skara to the repository. This could be a new WorkItem in the MailingListBridgeBot that monitors the label config file and updates each repository on changes.
Looking around in the Skara source, it seems the repository labels are queried for their description in the PR CLI command. The description in that case is expected to contain the mailing list which the label is associated with. The mainline jdk labels have this configured, but any labels that were automatically added to the jdk17 repository are missing this description. This goes for both Github and Gitlab.
The way labels work in Gitlab and Github is different. On github, we have the skara /label command to manually add labels. In Gitlab, this command is native, so is not handled by Skara at all. This difference is causing some different semantics when trying to add a new label for the first time in a particular repository. Gitlab will only let the /label command add labels that are preconfigured for the repository. On Github, because Skara is running the /label command, it seems that when adding a label through the rest api, it's automatically added to the repository. The only way new labels are added to repositories in Gitlab today is when Skara automatically matches code changes in a PR to a label, in which case Gitlab seem to accept new labels and add them to the repo if needed. What this means in practice is that users can't manually add a label until another PR has been created which automatically added that label.
Unfortunately, Gitlab does not provide any way to bulk import labels when we create a new fork. That would otherwise have been a convenient way to handle this.
I think we need to add some logic somewhere that syncs the label configuration from Skara to the repository. This could be a new WorkItem in the MailingListBridgeBot that monitors the label config file and updates each repository on changes.
Looking around in the Skara source, it seems the repository labels are queried for their description in the PR CLI command. The description in that case is expected to contain the mailing list which the label is associated with. The mainline jdk labels have this configured, but any labels that were automatically added to the jdk17 repository are missing this description. This goes for both Github and Gitlab.
