When renaming a GitLab group, this will break the package. It can not be updated anymore. In the UI you will see something like:
Error: File not found at Error: File not found at https://gitlab.example/api/v4/projects/[...]/repository/archive.zip?sha=f25a89db9a0a4ddfa18a7f423ef8d7a492aecfdb
Logs:
Reading composer.json of vendor/some-package (0.1.0)
Importing tag 0.1.0 (0.1.0.0)
Reading composer.json of vendor/some-package (0.2.0)
Importing tag 0.2.0 (0.2.0.0)
Reading composer.json of vendor/some-package (0.3.0)
Importing tag 0.3.0 (0.3.0.0)
Reading composer.json of vendor/some-package (0.4.0)
Importing tag 0.4.0 (0.4.0.0)
Reading composer.json of vendor/some-package (develop)
Importing branch develop (dev-develop)
Reading composer.json of vendor/some-package (master)
Importing branch master (dev-master)
Reading composer.json of vendor/some-package (support-jsm-serializer-30)
Importing branch support-jsm-serializer-30
If I'm not mistaken, the webhook payload does contain all repository URI information. So we could potentially update the repository URI for a package if this is different from what we have. Is this behaviour wanted?
When renaming a GitLab group, this will break the package. It can not be updated anymore. In the UI you will see something like:
If I'm not mistaken, the webhook payload does contain all repository URI information. So we could potentially update the repository URI for a package if this is different from what we have. Is this behaviour wanted?