Migration does not migrate attachments of issues on a given Gitea instance #152
Comments
I sent a message to the Gitea instance owner: |
|
The setup is made of a nginx redirecting to an Apache. I compared the BookStack nginx configuration with my This setup may be available at:The Stack Overflow answer 25755343 helps with Related to Benjamin_Loison/BookStack/issues/22. |
|
It is not an issue of domain name |
|
Same issue when migrate a repository with an issue attachment from the given Gitea instance to mine. |
|
However on OverClock3000: find /var/lib/gitea/ -name 'c1dd2c05-6be7-41a9-b0b5-2a87b5b5fb4a'Both URLs to the issue attachment:look correct, note that the file name is identical, either because it is enforced during the migration or because it is a hash of the file content. |
|
Investigating migration source code may help but is maybe not the most time efficient. |
Maybe I had to some extent this issue on my Gitea instance:Tracked at: |
The persons:do not use the concerned Gitea, so do not face this issue. |
Let us wait the domain name migration to
|
|
Same issue on Codeberg with Benjamin_Loison/Example_to_backup_attachments_of_issues/issues/1. See the target issue:I confirm that migrating from the secret instance to Codeberg, leads to the same issue, see Benjamin_Loison/Repository_with_an_actual_issue_attachment/issues/1. |
|
Should try between two Gitea instances without the secret one. If really a pain to setup another one as https://gitea-test.lemnoslife.com on another server, then could ask the person: |
After the migration I still notice the issue, see the message: |
|
Related to #46. |
|
Alternatively can make a script to upload attachments if possible. |
|
https://git.pole-recherche.fr/api/swagger#/issue/issueCreateIssueCommentAttachment curl -X 'POST' 'https://git.CENSORED.fr/api/v1/repos/Benjamin_Loison/Repository_with_an_issue_attachment/issues/comments/164/assets?name=elysee.svg' -H 'accept: application/json' -H 'Content-Type: multipart/form-data' -F '[email protected];type=image/svg+xml'Output:{"message":"token is required","url":"https://git.CENSORED.fr/api/swagger"} |
If add
|
|
Token Name: |
|
Do not proceed by hand as the new instance may be restored to a previous state as the migration is not officially completely finished as far as I understand. |
With the right permissions I now get:{
"message": "no matching issue comment found",
"url": "https://git.CENSORED.fr/api/swagger"
}https://git.CENSORED.fr/api/v1/repos/Benjamin_Loison/Repository_with_an_issue_attachment/issues/comments returns |
|
https://git.CENSORED.fr/Benjamin_Loison/Repository_with_an_issue_attachment/issues/1#issue-164 well it is an issue and not an issue comment... |
Bash script: curl -X 'POST' 'https://git.CENSORED.fr/api/v1/repos/Benjamin_Loison/Repository_with_an_issue_attachment/issues/1/assets?name=elysee.svg' -H 'accept: application/json' -H 'Content-Type: multipart/form-data' -F '[email protected];type=image/svg+xml' -H 'Authorization: token XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'Output:{
"id": 13,
"name": "elysee.svg",
"size": 20518,
"download_count": 0,
"created_at": "2025-04-11T19:26:06Z",
"uuid": "9e7db2f8-8bbb-408a-ae28-ba2f4a3cffb9",
"browser_download_url": "https://git.CENSORED.fr/attachments/9e7db2f8-8bbb-408a-ae28-ba2f4a3cffb9"
}so can't enforce the attachment id. Maybe because can't instance wide enforce it, like an issue comment id. However, correcting as most as possible in the repository is not enough as may have external references that we would like to hold even if the domain name changed. |
|
While can easily have issue comment id collision, attachment one seems less probable without a voluntary attack if it is not a file hash. |
|
So just passing a So let us work on generating such a |
|
Note that during the Gitea instance owner time of processing should not add new attachment to old source instance considered repository/ies. |
|
For generality let us not make a script leveraging running on source Gitea instance, hence having access to |
|
Maybe the number of folders to prefix the hash depends on the number of instance attachments, so should just provide a zip that the instance owner is able to adapt on its instance. If it is variable, then should prevent during adding attachments should pause write access to the instance at least. Maybe the attachments need to be tracked by a database not to be garbage collected or similar but we will figure out if it happens. |
|
Proceeding this way will lose attachment names but I can be fine with that, at least for a first iteration. Well maybe it is not that acceptable. |
https://codeberg.org/api/swagger#/issue/issueGetComments seems to face the same issue as Gitea, as the following person was wondering: |
|
Related to Benjamin_Loison/codeberg/issues/3. |
|
So compared to an attachment shown at least as an issue, not an issue comment, I don't see any difference, so can attach them as if there was no difference if possible: SELECT * FROM attachment WHERE uuid = '3127a3b4-XXXX-XXXX-XXXX-XXXXXXXXXXXX';Output: |
|
Benjamin_Loison/requests-cache/issues/3 would help. |
|
|
|
It is preferable to have the attachment exactly assigned to the issue (comment) it was on, so have to pay attention to unattached attachments but used elsewhere than their upload issue (comments). |
|
Could use |
|
Can download attachments as the last exportation step. |
|
Maybe can use a dictionary with |
Python script:array = [
{
'a': 42,
},
]
for element in array:
element = {
'b': 43,
}
print(array)[{'a': 42}]However, the Python script:for element in array:
element['b'] = 43[{'a': 42, 'b': 43}]Python script:for element in array:
element |= {
'b': 43,
}[{'a': 42, 'b': 43}] |
|
For unattached attachments, none of Well in fact |
len(requests.get('https://gitea.lemnoslife.com/Benjamin_Loison/CENSORED/attachments/061aba3a-XXXX-XXXX-XXXX-XXXXXXXXXXXX', cookies = {'i_like_gitea': I_LIKE_GITEA_COOKIE}).content)So it matches As it is a PNG my method seems binary resistant. |
print(json.dumps(dict(requests.get('https://gitea.lemnoslife.com/Benjamin_Loison/CENSORED/attachments/061aba3a-XXXX-XXXX-XXXX-XXXXXXXXXXXX', cookies = {'i_like_gitea': I_LIKE_GITEA_COOKIE}).headers), indent = 4))Output:{
"Server": "nginx/1.22.1",
"Date": "Thu, 24 Apr 2025 13:54:08 GMT",
"Content-Type": "image/png",
"Content-Length": "11472",
"Connection": "keep-alive",
"Accept-Ranges": "bytes",
"Access-Control-Expose-Headers": "Content-Disposition",
"Cache-Control": "private, max-age=300",
"Content-Disposition": "inline; filename=\"CENSORED.png\"; filename*=UTF-8''CENSORED",
"Etag": "\"061aba3a-XXXX-XXXX-XXXX-XXXXXXXXXXXX\"",
"Last-Modified": "Fri, 29 Mar 2024 01:12:01 GMT",
"No-Gzip-Compression": "1",
"Set-Cookie": "_csrf=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax",
"X-Content-Type-Options": "nosniff",
"X-Frame-Options": "SAMEORIGIN"
}date -d @1711674721so it seems that can also guess the |
|
DuckDuckGo search Python requests get file name. |
|
I doubt having used UTF-8 file names but adding support in the future would be nice. |
|
The Stack Overflow comment 113814041 helps getting the file name. |
|
Note that GMT is equivalent to UTC it seems. |
|
Let us avoid to precise default parameters in the JSON, even for parameters that may have a different values than the default one. So |
Note that the attachment of the issue comment:is missing. As this repository was not initially on Codeberg, the issue is not Codeberg silent deletion as in #46. |
|
Note that the cache can quickly get heavy as it is contains a copy of attachments. |
|
Benjamin_Loison/mysql/issues/13 would help. |
SELECT id, name from repository WHERE name in ('CENSORED_0', 'CENSORED_1');Output: |
DELETE FROM attachment WHERE repo_id IN (88, 89);
|
|
Should ensure that there is no attachment already in the target to correctly test but the aim is also to verify exhaustiveness of listing attachments at import, I suspect that deleting the repository is not perfect, removing all attachments would be preferable. |
cp -R /mnt/git/Gitea/gitea/gitea/{attachments,24_04_25_18_29}/
find /mnt/git/Gitea/gitea/gitea/attachments/ -type f -deletejust copying folder architecture would be more efficient. |
|
Note that specifying issue comment id is not possible most of the time as it is incremental. |
|
Benjamin_Loison/bash/issues/31 would help. |
|
The migration for more than 50 issue comments and attachments on the final instance seems successful. |
|
On the target instance I have verified that it works fine on multiple repositories, an issue, an issue comment and that a not attached attachment was now correctly migrated by being attached. |
Uh oh!
There was an error while loading. Please reload this page.
Description
To migrate a Gitea repository from https://gitea.lemnoslife.com with Issues need on https://gitea.lemnoslife.com/user/settings/applications Select permissions repository and issue Read.
However, as the target issue:
shows, the attachments are not imported, while they are important to me, in comparison the initial issue: https://gitea.lemnoslife.com/Benjamin_Loison/Repository_with_an_issue_attachment/issues/1
The attachment URL:
returns Not Found
Maybe due to URL
/git/introduction, related to Benjamin_Loison/nginx/issues/5.Creating a repository directly on the target instance make attachment upload and rendering fine in an issue.
Migrating from the target instance itself does not have the issue. It is because the attachment id already works fine, it keeps the issue comment as it is but not specify the attachments, so works fine.
Gitea Version
Not read.
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Not read.
Database
None
The text was updated successfully, but these errors were encountered: