All releases lost upon upgrading from Gogs to Gitea-1.3.2 #1395

@lafriks commented on GitHub (Dec 21, 2017):

API method could be added as I don't see where could it be added in admin interface

@lafriks commented on GitHub (Dec 21, 2017): API method could be added as I don't see where could it be added in admin interface

GiteaMirror commented

@strk commented on GitHub (Dec 21, 2017):

I'm doing an ./gitea admin repo-sync-releases-with-tags command. Want to help with that ? I dont' see how am I supposed to get the engine from model, although admin calls models.SetEngine() I don't see any models.GetEngine() function..

@strk commented on GitHub (Dec 21, 2017): I'm doing an `./gitea admin repo-sync-releases-with-tags` command. Want to help with that ? I dont' see how am I supposed to get the engine from model, although admin calls `models.SetEngine()` I don't see any `models.GetEngine()` function..

GiteaMirror commented

@lunny commented on GitHub (Dec 21, 2017):

That command should be help and seems it's easy to implementation.

@lunny commented on GitHub (Dec 21, 2017): That command should be help and seems it's easy to implementation.

GiteaMirror commented

@lunny commented on GitHub (Dec 21, 2017):

@strk which version was your Gogs? Maybe you lost some migrations?

@lunny commented on GitHub (Dec 21, 2017): @strk which version was your Gogs? Maybe you lost some migrations?

GiteaMirror commented

@lafriks commented on GitHub (Dec 21, 2017):

You need to call models function that does not require engine or create one

@lafriks commented on GitHub (Dec 21, 2017): You need to call models function that does not require engine or create one

GiteaMirror commented

@strk commented on GitHub (Dec 22, 2017):

Gogs-0.9.99.0903, with database at version 14.
The "release" table, present, was empty.

Model functions are not what the migration (v39.go) calls.
The migration does make use of x (the engine) to get the
list of repositories to scan/sync.

@strk commented on GitHub (Dec 22, 2017): Gogs-0.9.99.0903, with database at version 14. The "release" table, present, was empty. Model functions are not what the migration (v39.go) calls. The migration does make use of `x` (the engine) to get the list of repositories to scan/sync.

GiteaMirror commented

@strk commented on GitHub (Dec 22, 2017):

Actually, I went looking logs and found the probable cause of loosing
all those releases:

2017/10/18 13:27:11 [I] Migration: add tags to releases and sync existing repositories
2017/10/18 13:27:12 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any of the parent directories): .git
...
2017/10/18 13:27:12 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any of the parent directories): .git
2017/10/18 13:27:12 [I] Migration: remove duplicate unit types

There seem to be some problem with the repository paths.

@strk commented on GitHub (Dec 22, 2017): Actually, I went looking logs and found the probable cause of loosing all those releases: > 2017/10/18 13:27:11 [I] Migration: add tags to releases and sync existing repositories > 2017/10/18 13:27:12 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any of the parent directories): .git > ... > 2017/10/18 13:27:12 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any of the parent directories): .git > 2017/10/18 13:27:12 [I] Migration: remove duplicate unit types There seem to be some problem with the repository paths.

GiteaMirror commented

@strk commented on GitHub (Dec 30, 2017):

Working more on the PR adding an admin command to re-sync I found more problems: the function used by the migration supposed to synchronize repo tags with releases does not really work. Do you remember who changed the way releases were handled ?

@strk commented on GitHub (Dec 30, 2017): Working more on the PR adding an admin command to re-sync I found more problems: the function used by the migration supposed to synchronize repo tags with releases does not really work. Do you remember who changed the way releases were handled ?

GiteaMirror commented

@ethantkoenig commented on GitHub (Dec 30, 2017):

@strk I believe it was @lafriks: https://github.com/go-gitea/gitea/pull/2459

@ethantkoenig commented on GitHub (Dec 30, 2017): @strk I believe it was @lafriks: https://github.com/go-gitea/gitea/pull/2459

GiteaMirror commented

@strk commented on GitHub (Dec 30, 2017):

@lafriks can you check if things work for you ? Easy test:

Create test repository
Clone test repository locally (via commandline, from filesystem, not Gitea)
Add a tag, push the tag locally (via commandline, to filesystem, not Gitea)
Verify release tab does not show new tag
Run the ./gitea admin repo-sync-releases command, check output

For me, the final step does not add any new release record in the database, while I believe your migration 42 (from which code in this PR is taken) was meant to do exactly that ?

@strk commented on GitHub (Dec 30, 2017): @lafriks can you check if things work for you ? Easy test: 1. Create test repository 2. Clone test repository locally (via commandline, from filesystem, not Gitea) 3. Add a tag, push the tag locally (via commandline, to filesystem, not Gitea) 4. Verify release tab does not show new tag 5. Run the `./gitea admin repo-sync-releases` command, check output For me, the final step does not add any new release record in the database, while I believe your migration 42 (from which code in this PR is taken) was meant to do exactly that ?

GiteaMirror commented

@lafriks commented on GitHub (Dec 31, 2017):

@ethantkoenig @strk I fixed so that tags are actually displayed in release page and created that sync function but I was not one who broke displaying them in release page as before my PR tags would not be displayed in release page at all. I will try to reproduce your steps

@lafriks commented on GitHub (Dec 31, 2017): @ethantkoenig @strk I fixed so that tags are actually displayed in release page and created that sync function but I was not one who broke displaying them in release page as before my PR tags would not be displayed in release page at all. I will try to reproduce your steps

GiteaMirror commented

@strk commented on GitHub (Dec 31, 2017):

I fixed so that tags are actually displayed in release page
before my PR tags would not be displayed in release page at all

I don't understand the above two statements. What did you fix ?
What do you expect to see now in releases page ?
Do you have a reference to a ticket describing the problem you (tried to) fix ?

@strk commented on GitHub (Dec 31, 2017): > I fixed so that tags are actually displayed in release page > before my PR tags would not be displayed in release page at all I don't understand the above two statements. What did you fix ? What do you expect to see now in releases page ? Do you have a reference to a ticket describing the problem you (tried to) fix ?

GiteaMirror commented

@strk commented on GitHub (Dec 31, 2017):

self-answering the last question: previous ticket was https://github.com/go-gitea/gitea/issues/2154

@strk commented on GitHub (Dec 31, 2017): self-answering the last question: previous ticket was https://github.com/go-gitea/gitea/issues/2154

GiteaMirror commented

@lafriks commented on GitHub (Dec 31, 2017):

@strk can this be closed than?

@lafriks commented on GitHub (Dec 31, 2017): @strk can this be closed than?

GiteaMirror commented

@strk commented on GitHub (Dec 31, 2017):

I don't think so, we should try to reproduce the occurrence and
make the migration more tolerant. I was coming from Gogs 0.9.99.0903

@strk commented on GitHub (Dec 31, 2017): I don't think so, we should try to reproduce the occurrence and make the migration more tolerant. I was coming from Gogs 0.9.99.0903

GiteaMirror commented

@stale[bot] commented on GitHub (Feb 9, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 9, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented