Gitlab->Codeberg migration fails to copy tarballs attached to Releases #2031

jas commented 2025年07月19日 13:24:45 +02:00

Comment

Hi!

We recently migrated guile-gnutls from gitlab to codeberg, but the tarballs in the release pages are broken links, see:

https://codeberg.org/guile-gnutls/guile-gnutls/releases/tag/v4.0.1

And compare with:

https://gitlab.com/gnutls/guile/-/releases

Shouldn't that have resulted in migrated tarballs?

### Comment Hi! We recently migrated `guile-gnutls` from gitlab to codeberg, but the tarballs in the release pages are broken links, see: https://codeberg.org/guile-gnutls/guile-gnutls/releases/tag/v4.0.1 And compare with: https://gitlab.com/gnutls/guile/-/releases Shouldn't that have resulted in migrated tarballs?

Gusted commented 2025年07月19日 15:09:23 +02:00

@jas wrote in #2031 (comment):

Shouldn't that have resulted in migrated tarballs?

They are not part of the release as assets, they seem to be uploaded via the generic attachment route? The links broke because the original URL is quite simply /uploads/f80b3a30cfc66c988775edc4ce3fb546/guile-gnutls-4.0.1.tar.gz and Forgejo does not try to rewrite them to make them absolute (this also does not seem feasible because the absolute link is https://gitlab.com/-/project/40217954/uploads/f80b3a30cfc66c988775edc4ce3fb546/guile-gnutls-4.0.1.tar.gz and thus would requiring determining which project is hosting these uploads).

@jas wrote in https://codeberg.org/Codeberg/Community/issues/2031#issue-1951003: > Shouldn't that have resulted in migrated tarballs? They are not part of the release as assets, they seem to be uploaded via the generic attachment route? The links broke because the original URL is quite simply `/uploads/f80b3a30cfc66c988775edc4ce3fb546/guile-gnutls-4.0.1.tar.gz` and Forgejo does not try to rewrite them to make them absolute (this also does not seem feasible because the absolute link is https://gitlab.com/-/project/40217954/uploads/f80b3a30cfc66c988775edc4ce3fb546/guile-gnutls-4.0.1.tar.gz and thus would requiring determining which project is hosting these uploads).

jas commented 2025年07月19日 15:22:37 +02:00

Thanks for feedback! Yes indeed the gitlab release artifacts were made as a file attachment to the "release notes", not as a URL in the gitlab release assets list.

Looking at the codeberg release page, there doesn't seem to be any way to upload attachments to the text, right? So then I'm not sure what the best way to migrate such attachments from the gitlab release notes. Ideas:

1. Just modify the URL in the release notes to point at the old gitlab URL.
2. Add them as "external assets" with the URL pointing back at the gitlab URL. This doesn't seem optimal because then there is no complete migration.
3. Upload these attachments as codeberg release assets. This may be a bit confusing, since they weren't gitlab release assets, however these terms doesn't seem to map 1-to-1 between gitlab and codeberg. Gitlab allows attached files in the notes, but codeberg doesn't allow this, so something should happen to such attachments.

To clarify: this is a feature request, and it isn't clear exactly what the best forgejo-implementation of this feature would be. I'll let you and others continue to think about what to do about this situation.

Thanks for feedback! Yes indeed the gitlab release artifacts were made as a file attachment to the "release notes", not as a URL in the gitlab release assets list. Looking at the codeberg release page, there doesn't seem to be any way to upload attachments to the text, right? So then I'm not sure what the best way to migrate such attachments from the gitlab release notes. Ideas: 1) Just modify the URL in the release notes to point at the old gitlab URL. 2) Add them as "external assets" with the URL pointing back at the gitlab URL. This doesn't seem optimal because then there is no complete migration. 3) Upload these attachments as codeberg release assets. This may be a bit confusing, since they weren't gitlab release assets, however these terms doesn't seem to map 1-to-1 between gitlab and codeberg. Gitlab allows attached files in the notes, but codeberg doesn't allow this, so something should happen to such attachments. To clarify: this is a feature request, and it isn't clear exactly what the best forgejo-implementation of this feature would be. I'll let you and others continue to think about what to do about this situation.

Gusted commented 2025年07月19日 16:26:04 +02:00

@jas wrote in #2031 (comment):

Looking at the codeberg release page, there doesn't seem to be any way to upload attachments to the text, right? So then I'm not sure what the best way to migrate such attachments from the gitlab release notes. Ideas:

You can upload them as release asset and then include the link to that asset in the release message, but IMO that is reductive as the files would then be shown as release asset.

@jas wrote in #2031 (comment):

Gitlab allows attached files in the notes, but codeberg doesn't allow this, so something should happen to such attachments.

I don't really understand why they should be attached files? They are from my viewpoint release assets and having them as attached files does not seem to have any benefit.

@jas wrote in https://codeberg.org/Codeberg/Community/issues/2031#issuecomment-5894089: > Looking at the codeberg release page, there doesn't seem to be any way to upload attachments to the text, right? So then I'm not sure what the best way to migrate such attachments from the gitlab release notes. Ideas: You can upload them as release asset and then include the link to that asset in the release message, but IMO that is reductive as the files would then be shown as release asset. @jas wrote in https://codeberg.org/Codeberg/Community/issues/2031#issuecomment-5894089: > Gitlab allows attached files in the notes, but codeberg doesn't allow this, so something should happen to such attachments. I don't really understand why they should be attached files? They are from my viewpoint release assets and having them as attached files does not seem to have any benefit.

jas commented 2025年07月19日 20:27:50 +02:00

Having them show up as release assets on codeberg would be fine, I think. Anything that doesn't result in 404 URLs seems better than the current way.

Having them show up as release assets on codeberg would be fine, I think. Anything that doesn't result in 404 URLs seems better than the current way.