|
|
|
// Copyright 2019 The Gitea Authors. All rights reserved.
|
|
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
|
|
|
|
package migrations
|
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
|
|
|
"errors"
|
|
|
|
"fmt"
|
|
|
|
"io"
|
|
|
|
"net/http"
|
|
|
|
"net/url"
|
|
|
|
"path"
|
|
|
|
"strings"
|
|
|
|
"time"
|
|
|
|
|
|
|
|
"code.gitea.io/gitea/modules/log"
|
|
|
|
base "code.gitea.io/gitea/modules/migration"
|
|
|
|
"code.gitea.io/gitea/modules/structs"
|
|
|
|
|
|
|
|
"github.com/xanzy/go-gitlab"
|
|
|
|
)
|
|
|
|
|
|
|
|
var (
|
|
|
|
_ base.Downloader = &GitlabDownloader{}
|
|
|
|
_ base.DownloaderFactory = &GitlabDownloaderFactory{}
|
|
|
|
)
|
|
|
|
|
|
|
|
func init() {
|
|
|
|
RegisterDownloaderFactory(&GitlabDownloaderFactory{})
|
|
|
|
}
|
|
|
|
|
|
|
|
// GitlabDownloaderFactory defines a gitlab downloader factory
|
|
|
|
type GitlabDownloaderFactory struct{}
|
|
|
|
|
|
|
|
// New returns a Downloader related to this factory according MigrateOptions
|
|
|
|
func (f *GitlabDownloaderFactory) New(ctx context.Context, opts base.MigrateOptions) (base.Downloader, error) {
|
|
|
|
u, err := url.Parse(opts.CloneAddr)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
baseURL := u.Scheme + "://" + u.Host
|
|
|
|
repoNameSpace := strings.TrimPrefix(u.Path, "/")
|
|
|
|
repoNameSpace = strings.TrimSuffix(repoNameSpace, ".git")
|
|
|
|
|
|
|
|
log.Trace("Create gitlab downloader. BaseURL: %s RepoName: %s", baseURL, repoNameSpace)
|
|
|
|
|
|
|
|
return NewGitlabDownloader(ctx, baseURL, repoNameSpace, opts.AuthUsername, opts.AuthPassword, opts.AuthToken)
|
|
|
|
}
|
|
|
|
|
|
|
|
// GitServiceType returns the type of git service
|
|
|
|
func (f *GitlabDownloaderFactory) GitServiceType() structs.GitServiceType {
|
|
|
|
return structs.GitlabService
|
|
|
|
}
|
|
|
|
|
|
|
|
// GitlabDownloader implements a Downloader interface to get repository information
|
|
|
|
// from gitlab via go-gitlab
|
|
|
|
// - issueCount is incremented in GetIssues() to ensure PR and Issue numbers do not overlap,
|
|
|
|
// because Gitlab has individual Issue and Pull Request numbers.
|
|
|
|
type GitlabDownloader struct {
|
|
|
|
base.NullDownloader
|
|
|
|
ctx context.Context
|
|
|
|
client *gitlab.Client
|
|
|
|
baseURL string
|
|
|
|
repoID int
|
|
|
|
repoName string
|
|
|
|
issueCount int64
|
|
|
|
maxPerPage int
|
|
|
|
}
|
|
|
|
|
|
|
|
// NewGitlabDownloader creates a gitlab Downloader via gitlab API
|
|
|
|
//
|
|
|
|
// Use either a username/password, personal token entered into the username field, or anonymous/public access
|
|
|
|
// Note: Public access only allows very basic access
|
|
|
|
func NewGitlabDownloader(ctx context.Context, baseURL, repoPath, username, password, token string) (*GitlabDownloader, error) {
|
|
|
|
gitlabClient, err := gitlab.NewClient(token, gitlab.WithBaseURL(baseURL), gitlab.WithHTTPClient(NewMigrationHTTPClient()))
|
|
|
|
// Only use basic auth if token is blank and password is NOT
|
|
|
|
// Basic auth will fail with empty strings, but empty token will allow anonymous public API usage
|
|
|
|
if token == "" && password != "" {
|
|
|
|
gitlabClient, err = gitlab.NewBasicAuthClient(username, password, gitlab.WithBaseURL(baseURL), gitlab.WithHTTPClient(NewMigrationHTTPClient()))
|
|
|
|
}
|
|
|
|
|
|
|
|
if err != nil {
|
|
|
|
log.Trace("Error logging into gitlab: %v", err)
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// split namespace and subdirectory
|
|
|
|
pathParts := strings.Split(strings.Trim(repoPath, "/"), "/")
|
|
|
|
var resp *gitlab.Response
|
|
|
|
u, _ := url.Parse(baseURL)
|
|
|
|
for len(pathParts) >= 2 {
|
|
|
|
_, resp, err = gitlabClient.Version.GetVersion()
|
|
|
|
if err == nil || resp != nil && resp.StatusCode == http.StatusUnauthorized {
|
|
|
|
err = nil // if no authentication given, this still should work
|
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
u.Path = path.Join(u.Path, pathParts[0])
|
|
|
|
baseURL = u.String()
|
|
|
|
pathParts = pathParts[1:]
|
|
|
|
_ = gitlab.WithBaseURL(baseURL)(gitlabClient)
|
|
|
|
repoPath = strings.Join(pathParts, "/")
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
log.Trace("Error could not get gitlab version: %v", err)
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
log.Trace("gitlab downloader: use BaseURL: '%s' and RepoPath: '%s'", baseURL, repoPath)
|
|
|
|
|
|
|
|
// Grab and store project/repo ID here, due to issues using the URL escaped path
|
|
|
|
gr, _, err := gitlabClient.Projects.GetProject(repoPath, nil, nil, gitlab.WithContext(ctx))
|
|
|
|
if err != nil {
|
|
|
|
log.Trace("Error retrieving project: %v", err)
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
if gr == nil {
|
|
|
|
log.Trace("Error getting project, project is nil")
|
|
|
|
return nil, errors.New("Error getting project, project is nil")
|
|
|
|
}
|
|
|
|
|
|
|
|
return &GitlabDownloader{
|
|
|
|
ctx: ctx,
|
|
|
|
client: gitlabClient,
|
|
|
|
baseURL: baseURL,
|
|
|
|
repoID: gr.ID,
|
|
|
|
repoName: gr.Name,
|
|
|
|
maxPerPage: 100,
|
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// String implements Stringer
|
|
|
|
func (g *GitlabDownloader) String() string {
|
|
|
|
return fmt.Sprintf("migration from gitlab server %s [%d]/%s", g.baseURL, g.repoID, g.repoName)
|
|
|
|
}
|
|
|
|
|
Rewrite logger system (#24726)
## ⚠️ Breaking
The `log.<mode>.<logger>` style config has been dropped. If you used it,
please check the new config manual & app.example.ini to make your
instance output logs as expected.
Although many legacy options still work, it's encouraged to upgrade to
the new options.
The SMTP logger is deleted because SMTP is not suitable to collect logs.
If you have manually configured Gitea log options, please confirm the
logger system works as expected after upgrading.
## Description
Close #12082 and maybe more log-related issues, resolve some related
FIXMEs in old code (which seems unfixable before)
Just like rewriting queue #24505 : make code maintainable, clear legacy
bugs, and add the ability to support more writers (eg: JSON, structured
log)
There is a new document (with examples): `logging-config.en-us.md`
This PR is safer than the queue rewriting, because it's just for
logging, it won't break other logic.
## The old problems
The logging system is quite old and difficult to maintain:
* Unclear concepts: Logger, NamedLogger, MultiChannelledLogger,
SubLogger, EventLogger, WriterLogger etc
* Some code is diffuclt to konw whether it is right:
`log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs
`log.DelLogger("console")`
* The old system heavily depends on ini config system, it's difficult to
create new logger for different purpose, and it's very fragile.
* The "color" trick is difficult to use and read, many colors are
unnecessary, and in the future structured log could help
* It's difficult to add other log formats, eg: JSON format
* The log outputer doesn't have full control of its goroutine, it's
difficult to make outputer have advanced behaviors
* The logs could be lost in some cases: eg: no Fatal error when using
CLI.
* Config options are passed by JSON, which is quite fragile.
* INI package makes the KEY in `[log]` section visible in `[log.sub1]`
and `[log.sub1.subA]`, this behavior is quite fragile and would cause
more unclear problems, and there is no strong requirement to support
`log.<mode>.<logger>` syntax.
## The new design
See `logger.go` for documents.
## Screenshot
<details>
![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff)
![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9)
![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee)
</details>
## TODO
* [x] add some new tests
* [x] fix some tests
* [x] test some sub-commands (manually ....)
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
2 years ago
|
|
|
func (g *GitlabDownloader) LogString() string {
|
|
|
|
if g == nil {
|
Rewrite logger system (#24726)
## ⚠️ Breaking
The `log.<mode>.<logger>` style config has been dropped. If you used it,
please check the new config manual & app.example.ini to make your
instance output logs as expected.
Although many legacy options still work, it's encouraged to upgrade to
the new options.
The SMTP logger is deleted because SMTP is not suitable to collect logs.
If you have manually configured Gitea log options, please confirm the
logger system works as expected after upgrading.
## Description
Close #12082 and maybe more log-related issues, resolve some related
FIXMEs in old code (which seems unfixable before)
Just like rewriting queue #24505 : make code maintainable, clear legacy
bugs, and add the ability to support more writers (eg: JSON, structured
log)
There is a new document (with examples): `logging-config.en-us.md`
This PR is safer than the queue rewriting, because it's just for
logging, it won't break other logic.
## The old problems
The logging system is quite old and difficult to maintain:
* Unclear concepts: Logger, NamedLogger, MultiChannelledLogger,
SubLogger, EventLogger, WriterLogger etc
* Some code is diffuclt to konw whether it is right:
`log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs
`log.DelLogger("console")`
* The old system heavily depends on ini config system, it's difficult to
create new logger for different purpose, and it's very fragile.
* The "color" trick is difficult to use and read, many colors are
unnecessary, and in the future structured log could help
* It's difficult to add other log formats, eg: JSON format
* The log outputer doesn't have full control of its goroutine, it's
difficult to make outputer have advanced behaviors
* The logs could be lost in some cases: eg: no Fatal error when using
CLI.
* Config options are passed by JSON, which is quite fragile.
* INI package makes the KEY in `[log]` section visible in `[log.sub1]`
and `[log.sub1.subA]`, this behavior is quite fragile and would cause
more unclear problems, and there is no strong requirement to support
`log.<mode>.<logger>` syntax.
## The new design
See `logger.go` for documents.
## Screenshot
<details>
![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff)
![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9)
![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee)
</details>
## TODO
* [x] add some new tests
* [x] fix some tests
* [x] test some sub-commands (manually ....)
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
2 years ago
|
|
|
return "<GitlabDownloader nil>"
|
|
|
|
}
|
Rewrite logger system (#24726)
## ⚠️ Breaking
The `log.<mode>.<logger>` style config has been dropped. If you used it,
please check the new config manual & app.example.ini to make your
instance output logs as expected.
Although many legacy options still work, it's encouraged to upgrade to
the new options.
The SMTP logger is deleted because SMTP is not suitable to collect logs.
If you have manually configured Gitea log options, please confirm the
logger system works as expected after upgrading.
## Description
Close #12082 and maybe more log-related issues, resolve some related
FIXMEs in old code (which seems unfixable before)
Just like rewriting queue #24505 : make code maintainable, clear legacy
bugs, and add the ability to support more writers (eg: JSON, structured
log)
There is a new document (with examples): `logging-config.en-us.md`
This PR is safer than the queue rewriting, because it's just for
logging, it won't break other logic.
## The old problems
The logging system is quite old and difficult to maintain:
* Unclear concepts: Logger, NamedLogger, MultiChannelledLogger,
SubLogger, EventLogger, WriterLogger etc
* Some code is diffuclt to konw whether it is right:
`log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs
`log.DelLogger("console")`
* The old system heavily depends on ini config system, it's difficult to
create new logger for different purpose, and it's very fragile.
* The "color" trick is difficult to use and read, many colors are
unnecessary, and in the future structured log could help
* It's difficult to add other log formats, eg: JSON format
* The log outputer doesn't have full control of its goroutine, it's
difficult to make outputer have advanced behaviors
* The logs could be lost in some cases: eg: no Fatal error when using
CLI.
* Config options are passed by JSON, which is quite fragile.
* INI package makes the KEY in `[log]` section visible in `[log.sub1]`
and `[log.sub1.subA]`, this behavior is quite fragile and would cause
more unclear problems, and there is no strong requirement to support
`log.<mode>.<logger>` syntax.
## The new design
See `logger.go` for documents.
## Screenshot
<details>
![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff)
![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9)
![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee)
</details>
## TODO
* [x] add some new tests
* [x] fix some tests
* [x] test some sub-commands (manually ....)
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: Giteabot <teabot@gitea.io>
2 years ago
|
|
|
return fmt.Sprintf("<GitlabDownloader %s [%d]/%s>", g.baseURL, g.repoID, g.repoName)
|
|
|
|
}
|
|
|
|
|
|
|
|
// SetContext set context
|
|
|
|
func (g *GitlabDownloader) SetContext(ctx context.Context) {
|
|
|
|
g.ctx = ctx
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetRepoInfo returns a repository information
|
|
|
|
func (g *GitlabDownloader) GetRepoInfo() (*base.Repository, error) {
|
|
|
|
gr, _, err := g.client.Projects.GetProject(g.repoID, nil, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
var private bool
|
|
|
|
switch gr.Visibility {
|
|
|
|
case gitlab.InternalVisibility:
|
|
|
|
private = true
|
|
|
|
case gitlab.PrivateVisibility:
|
|
|
|
private = true
|
|
|
|
}
|
|
|
|
|
|
|
|
var owner string
|
|
|
|
if gr.Owner == nil {
|
|
|
|
log.Trace("gr.Owner is nil, trying to get owner from Namespace")
|
|
|
|
if gr.Namespace != nil && gr.Namespace.Kind == "user" {
|
|
|
|
owner = gr.Namespace.Path
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
owner = gr.Owner.Username
|
|
|
|
}
|
|
|
|
|
|
|
|
// convert gitlab repo to stand Repo
|
|
|
|
return &base.Repository{
|
|
|
|
Owner: owner,
|
|
|
|
Name: gr.Name,
|
|
|
|
IsPrivate: private,
|
|
|
|
Description: gr.Description,
|
|
|
|
OriginalURL: gr.WebURL,
|
|
|
|
CloneURL: gr.HTTPURLToRepo,
|
|
|
|
DefaultBranch: gr.DefaultBranch,
|
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetTopics return gitlab topics
|
|
|
|
func (g *GitlabDownloader) GetTopics() ([]string, error) {
|
|
|
|
gr, _, err := g.client.Projects.GetProject(g.repoID, nil, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return gr.TagList, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetMilestones returns milestones
|
|
|
|
func (g *GitlabDownloader) GetMilestones() ([]*base.Milestone, error) {
|
|
|
|
perPage := g.maxPerPage
|
|
|
|
state := "all"
|
|
|
|
milestones := make([]*base.Milestone, 0, perPage)
|
|
|
|
for i := 1; ; i++ {
|
|
|
|
ms, _, err := g.client.Milestones.ListMilestones(g.repoID, &gitlab.ListMilestonesOptions{
|
|
|
|
State: &state,
|
|
|
|
ListOptions: gitlab.ListOptions{
|
|
|
|
Page: i,
|
|
|
|
PerPage: perPage,
|
|
|
|
},
|
|
|
|
}, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, m := range ms {
|
|
|
|
var desc string
|
|
|
|
if m.Description != "" {
|
|
|
|
desc = m.Description
|
|
|
|
}
|
|
|
|
state := "open"
|
|
|
|
var closedAt *time.Time
|
|
|
|
if m.State != "" {
|
|
|
|
state = m.State
|
|
|
|
if state == "closed" {
|
|
|
|
closedAt = m.UpdatedAt
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var deadline *time.Time
|
|
|
|
if m.DueDate != nil {
|
|
|
|
deadlineParsed, err := time.Parse("2006-01-02", m.DueDate.String())
|
|
|
|
if err != nil {
|
|
|
|
log.Trace("Error parsing Milestone DueDate time")
|
|
|
|
deadline = nil
|
|
|
|
} else {
|
|
|
|
deadline = &deadlineParsed
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
milestones = append(milestones, &base.Milestone{
|
|
|
|
Title: m.Title,
|
|
|
|
Description: desc,
|
|
|
|
Deadline: deadline,
|
|
|
|
State: state,
|
|
|
|
Created: *m.CreatedAt,
|
|
|
|
Updated: m.UpdatedAt,
|
|
|
|
Closed: closedAt,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
if len(ms) < perPage {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return milestones, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (g *GitlabDownloader) normalizeColor(val string) string {
|
|
|
|
val = strings.TrimLeft(val, "#")
|
|
|
|
val = strings.ToLower(val)
|
|
|
|
if len(val) == 3 {
|
|
|
|
c := []rune(val)
|
|
|
|
val = fmt.Sprintf("%c%c%c%c%c%c", c[0], c[0], c[1], c[1], c[2], c[2])
|
|
|
|
}
|
|
|
|
if len(val) != 6 {
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
return val
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetLabels returns labels
|
|
|
|
func (g *GitlabDownloader) GetLabels() ([]*base.Label, error) {
|
|
|
|
perPage := g.maxPerPage
|
|
|
|
labels := make([]*base.Label, 0, perPage)
|
|
|
|
for i := 1; ; i++ {
|
|
|
|
ls, _, err := g.client.Labels.ListLabels(g.repoID, &gitlab.ListLabelsOptions{ListOptions: gitlab.ListOptions{
|
|
|
|
Page: i,
|
|
|
|
PerPage: perPage,
|
|
|
|
}}, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
for _, label := range ls {
|
|
|
|
baseLabel := &base.Label{
|
|
|
|
Name: label.Name,
|
|
|
|
Color: g.normalizeColor(label.Color),
|
|
|
|
Description: label.Description,
|
|
|
|
}
|
|
|
|
labels = append(labels, baseLabel)
|
|
|
|
}
|
|
|
|
if len(ls) < perPage {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return labels, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (g *GitlabDownloader) convertGitlabRelease(rel *gitlab.Release) *base.Release {
|
|
|
|
var zero int
|
|
|
|
r := &base.Release{
|
|
|
|
TagName: rel.TagName,
|
|
|
|
TargetCommitish: rel.Commit.ID,
|
|
|
|
Name: rel.Name,
|
|
|
|
Body: rel.Description,
|
|
|
|
Created: *rel.CreatedAt,
|
|
|
|
PublisherID: int64(rel.Author.ID),
|
|
|
|
PublisherName: rel.Author.Username,
|
|
|
|
}
|
|
|
|
|
|
|
|
httpClient := NewMigrationHTTPClient()
|
|
|
|
|
|
|
|
for k, asset := range rel.Assets.Links {
|
|
|
|
r.Assets = append(r.Assets, &base.ReleaseAsset{
|
|
|
|
ID: int64(asset.ID),
|
|
|
|
Name: asset.Name,
|
|
|
|
ContentType: &rel.Assets.Sources[k].Format,
|
|
|
|
Size: &zero,
|
|
|
|
DownloadCount: &zero,
|
|
|
|
DownloadFunc: func() (io.ReadCloser, error) {
|
|
|
|
link, _, err := g.client.ReleaseLinks.GetReleaseLink(g.repoID, rel.TagName, asset.ID, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
if !hasBaseURL(link.URL, g.baseURL) {
|
|
|
|
WarnAndNotice("Unexpected AssetURL for assetID[%d] in %s: %s", asset.ID, g, link.URL)
|
|
|
|
return io.NopCloser(strings.NewReader(link.URL)), nil
|
|
|
|
}
|
|
|
|
|
|
|
|
req, err := http.NewRequest("GET", link.URL, nil)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
req = req.WithContext(g.ctx)
|
|
|
|
resp, err := httpClient.Do(req)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
// resp.Body is closed by the uploader
|
|
|
|
return resp.Body, nil
|
|
|
|
},
|
|
|
|
})
|
|
|
|
}
|
|
|
|
return r
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetReleases returns releases
|
|
|
|
func (g *GitlabDownloader) GetReleases() ([]*base.Release, error) {
|
|
|
|
perPage := g.maxPerPage
|
|
|
|
releases := make([]*base.Release, 0, perPage)
|
|
|
|
for i := 1; ; i++ {
|
|
|
|
ls, _, err := g.client.Releases.ListReleases(g.repoID, &gitlab.ListReleasesOptions{
|
|
|
|
ListOptions: gitlab.ListOptions{
|
|
|
|
Page: i,
|
|
|
|
PerPage: perPage,
|
|
|
|
},
|
|
|
|
}, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, release := range ls {
|
|
|
|
releases = append(releases, g.convertGitlabRelease(release))
|
|
|
|
}
|
|
|
|
if len(ls) < perPage {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return releases, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
type gitlabIssueContext struct {
|
|
|
|
IsMergeRequest bool
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetIssues returns issues according start and limit
|
|
|
|
//
|
|
|
|
// Note: issue label description and colors are not supported by the go-gitlab library at this time
|
|
|
|
func (g *GitlabDownloader) GetIssues(page, perPage int) ([]*base.Issue, bool, error) {
|
|
|
|
state := "all"
|
|
|
|
sort := "asc"
|
|
|
|
|
|
|
|
if perPage > g.maxPerPage {
|
|
|
|
perPage = g.maxPerPage
|
|
|
|
}
|
|
|
|
|
|
|
|
opt := &gitlab.ListProjectIssuesOptions{
|
|
|
|
State: &state,
|
|
|
|
Sort: &sort,
|
|
|
|
ListOptions: gitlab.ListOptions{
|
|
|
|
PerPage: perPage,
|
|
|
|
Page: page,
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
allIssues := make([]*base.Issue, 0, perPage)
|
|
|
|
|
|
|
|
issues, _, err := g.client.Issues.ListProjectIssues(g.repoID, opt, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, fmt.Errorf("error while listing issues: %w", err)
|
|
|
|
}
|
|
|
|
for _, issue := range issues {
|
|
|
|
|
|
|
|
labels := make([]*base.Label, 0, len(issue.Labels))
|
|
|
|
for _, l := range issue.Labels {
|
|
|
|
labels = append(labels, &base.Label{
|
|
|
|
Name: l,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
var milestone string
|
|
|
|
if issue.Milestone != nil {
|
|
|
|
milestone = issue.Milestone.Title
|
|
|
|
}
|
|
|
|
|
|
|
|
var reactions []*gitlab.AwardEmoji
|
|
|
|
awardPage := 1
|
|
|
|
for {
|
|
|
|
awards, _, err := g.client.AwardEmoji.ListIssueAwardEmoji(g.repoID, issue.IID, &gitlab.ListAwardEmojiOptions{Page: awardPage, PerPage: perPage}, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, fmt.Errorf("error while listing issue awards: %w", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
reactions = append(reactions, awards...)
|
|
|
|
|
|
|
|
if len(awards) < perPage {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
awardPage++
|
|
|
|
}
|
|
|
|
|
|
|
|
allIssues = append(allIssues, &base.Issue{
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
Title: issue.Title,
|
|
|
|
Number: int64(issue.IID),
|
|
|
|
PosterID: int64(issue.Author.ID),
|
|
|
|
PosterName: issue.Author.Username,
|
|
|
|
Content: issue.Description,
|
|
|
|
Milestone: milestone,
|
|
|
|
State: issue.State,
|
|
|
|
Created: *issue.CreatedAt,
|
|
|
|
Labels: labels,
|
|
|
|
Reactions: g.awardsToReactions(reactions),
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
Closed: issue.ClosedAt,
|
|
|
|
IsLocked: issue.DiscussionLocked,
|
|
|
|
Updated: *issue.UpdatedAt,
|
|
|
|
ForeignIndex: int64(issue.IID),
|
|
|
|
Context: gitlabIssueContext{IsMergeRequest: false},
|
|
|
|
})
|
|
|
|
|
|
|
|
// increment issueCount, to be used in GetPullRequests()
|
|
|
|
g.issueCount++
|
|
|
|
}
|
|
|
|
|
|
|
|
return allIssues, len(issues) < perPage, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetComments returns comments according issueNumber
|
|
|
|
// TODO: figure out how to transfer comment reactions
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
func (g *GitlabDownloader) GetComments(commentable base.Commentable) ([]*base.Comment, bool, error) {
|
|
|
|
context, ok := commentable.GetContext().(gitlabIssueContext)
|
|
|
|
if !ok {
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
return nil, false, fmt.Errorf("unexpected context: %+v", commentable.GetContext())
|
|
|
|
}
|
|
|
|
|
|
|
|
allComments := make([]*base.Comment, 0, g.maxPerPage)
|
|
|
|
|
|
|
|
page := 1
|
|
|
|
|
|
|
|
for {
|
|
|
|
var comments []*gitlab.Discussion
|
|
|
|
var resp *gitlab.Response
|
|
|
|
var err error
|
|
|
|
if !context.IsMergeRequest {
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
comments, resp, err = g.client.Discussions.ListIssueDiscussions(g.repoID, int(commentable.GetForeignIndex()), &gitlab.ListIssueDiscussionsOptions{
|
|
|
|
Page: page,
|
|
|
|
PerPage: g.maxPerPage,
|
|
|
|
}, nil, gitlab.WithContext(g.ctx))
|
|
|
|
} else {
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
comments, resp, err = g.client.Discussions.ListMergeRequestDiscussions(g.repoID, int(commentable.GetForeignIndex()), &gitlab.ListMergeRequestDiscussionsOptions{
|
|
|
|
Page: page,
|
|
|
|
PerPage: g.maxPerPage,
|
|
|
|
}, nil, gitlab.WithContext(g.ctx))
|
|
|
|
}
|
|
|
|
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, fmt.Errorf("error while listing comments: %v %w", g.repoID, err)
|
|
|
|
}
|
|
|
|
for _, comment := range comments {
|
|
|
|
// Flatten comment threads
|
|
|
|
if !comment.IndividualNote {
|
|
|
|
for _, note := range comment.Notes {
|
|
|
|
allComments = append(allComments, &base.Comment{
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
IssueIndex: commentable.GetLocalIndex(),
|
|
|
|
Index: int64(note.ID),
|
|
|
|
PosterID: int64(note.Author.ID),
|
|
|
|
PosterName: note.Author.Username,
|
|
|
|
PosterEmail: note.Author.Email,
|
|
|
|
Content: note.Body,
|
|
|
|
Created: *note.CreatedAt,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
c := comment.Notes[0]
|
|
|
|
allComments = append(allComments, &base.Comment{
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
IssueIndex: commentable.GetLocalIndex(),
|
|
|
|
Index: int64(c.ID),
|
|
|
|
PosterID: int64(c.Author.ID),
|
|
|
|
PosterName: c.Author.Username,
|
|
|
|
PosterEmail: c.Author.Email,
|
|
|
|
Content: c.Body,
|
|
|
|
Created: *c.CreatedAt,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if resp.NextPage == 0 {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
page = resp.NextPage
|
|
|
|
}
|
|
|
|
return allComments, true, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetPullRequests returns pull requests according page and perPage
|
|
|
|
func (g *GitlabDownloader) GetPullRequests(page, perPage int) ([]*base.PullRequest, bool, error) {
|
|
|
|
if perPage > g.maxPerPage {
|
|
|
|
perPage = g.maxPerPage
|
|
|
|
}
|
|
|
|
|
|
|
|
opt := &gitlab.ListProjectMergeRequestsOptions{
|
|
|
|
ListOptions: gitlab.ListOptions{
|
|
|
|
PerPage: perPage,
|
|
|
|
Page: page,
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
allPRs := make([]*base.PullRequest, 0, perPage)
|
|
|
|
|
|
|
|
prs, _, err := g.client.MergeRequests.ListProjectMergeRequests(g.repoID, opt, nil, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, fmt.Errorf("error while listing merge requests: %w", err)
|
|
|
|
}
|
|
|
|
for _, pr := range prs {
|
|
|
|
|
|
|
|
labels := make([]*base.Label, 0, len(pr.Labels))
|
|
|
|
for _, l := range pr.Labels {
|
|
|
|
labels = append(labels, &base.Label{
|
|
|
|
Name: l,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
var merged bool
|
|
|
|
if pr.State == "merged" {
|
|
|
|
merged = true
|
|
|
|
pr.State = "closed"
|
|
|
|
}
|
|
|
|
|
|
|
|
mergeTime := pr.MergedAt
|
|
|
|
if merged && pr.MergedAt == nil {
|
|
|
|
mergeTime = pr.UpdatedAt
|
|
|
|
}
|
|
|
|
|
|
|
|
closeTime := pr.ClosedAt
|
|
|
|
if merged && pr.ClosedAt == nil {
|
|
|
|
closeTime = pr.UpdatedAt
|
|
|
|
}
|
|
|
|
|
|
|
|
var locked bool
|
|
|
|
if pr.State == "locked" {
|
|
|
|
locked = true
|
|
|
|
}
|
|
|
|
|
|
|
|
var milestone string
|
|
|
|
if pr.Milestone != nil {
|
|
|
|
milestone = pr.Milestone.Title
|
|
|
|
}
|
|
|
|
|
|
|
|
var reactions []*gitlab.AwardEmoji
|
|
|
|
awardPage := 1
|
|
|
|
for {
|
|
|
|
awards, _, err := g.client.AwardEmoji.ListMergeRequestAwardEmoji(g.repoID, pr.IID, &gitlab.ListAwardEmojiOptions{Page: awardPage, PerPage: perPage}, gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
return nil, false, fmt.Errorf("error while listing merge requests awards: %w", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
reactions = append(reactions, awards...)
|
|
|
|
|
|
|
|
if len(awards) < perPage {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
awardPage++
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add the PR ID to the Issue Count because PR and Issues share ID space in Gitea
|
|
|
|
newPRNumber := g.issueCount + int64(pr.IID)
|
|
|
|
|
|
|
|
allPRs = append(allPRs, &base.PullRequest{
|
|
|
|
Title: pr.Title,
|
|
|
|
Number: newPRNumber,
|
|
|
|
PosterName: pr.Author.Username,
|
|
|
|
PosterID: int64(pr.Author.ID),
|
|
|
|
Content: pr.Description,
|
|
|
|
Milestone: milestone,
|
|
|
|
State: pr.State,
|
|
|
|
Created: *pr.CreatedAt,
|
|
|
|
Closed: closeTime,
|
|
|
|
Labels: labels,
|
|
|
|
Merged: merged,
|
|
|
|
MergeCommitSHA: pr.MergeCommitSHA,
|
|
|
|
MergedTime: mergeTime,
|
|
|
|
IsLocked: locked,
|
|
|
|
Reactions: g.awardsToReactions(reactions),
|
|
|
|
Head: base.PullRequestBranch{
|
|
|
|
Ref: pr.SourceBranch,
|
|
|
|
SHA: pr.SHA,
|
|
|
|
RepoName: g.repoName,
|
|
|
|
OwnerName: pr.Author.Username,
|
|
|
|
CloneURL: pr.WebURL,
|
|
|
|
},
|
|
|
|
Base: base.PullRequestBranch{
|
|
|
|
Ref: pr.TargetBranch,
|
|
|
|
SHA: pr.DiffRefs.BaseSha,
|
|
|
|
RepoName: g.repoName,
|
|
|
|
OwnerName: pr.Author.Username,
|
|
|
|
},
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
PatchURL: pr.WebURL + ".patch",
|
|
|
|
ForeignIndex: int64(pr.IID),
|
|
|
|
Context: gitlabIssueContext{IsMergeRequest: true},
|
|
|
|
})
|
|
|
|
|
|
|
|
// SECURITY: Ensure that the PR is safe
|
|
|
|
_ = CheckAndEnsureSafePR(allPRs[len(allPRs)-1], g.baseURL, g)
|
|
|
|
}
|
|
|
|
|
|
|
|
return allPRs, len(prs) < perPage, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetReviews returns pull requests review
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
func (g *GitlabDownloader) GetReviews(reviewable base.Reviewable) ([]*base.Review, error) {
|
|
|
|
approvals, resp, err := g.client.MergeRequestApprovals.GetConfiguration(g.repoID, int(reviewable.GetForeignIndex()), gitlab.WithContext(g.ctx))
|
|
|
|
if err != nil {
|
|
|
|
if resp != nil && resp.StatusCode == http.StatusNotFound {
|
|
|
|
log.Error(fmt.Sprintf("GitlabDownloader: while migrating a error occurred: '%s'", err.Error()))
|
|
|
|
return []*base.Review{}, nil
|
|
|
|
}
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
var createdAt time.Time
|
|
|
|
if approvals.CreatedAt != nil {
|
|
|
|
createdAt = *approvals.CreatedAt
|
|
|
|
} else if approvals.UpdatedAt != nil {
|
|
|
|
createdAt = *approvals.UpdatedAt
|
|
|
|
} else {
|
|
|
|
createdAt = time.Now()
|
|
|
|
}
|
|
|
|
|
|
|
|
reviews := make([]*base.Review, 0, len(approvals.ApprovedBy))
|
|
|
|
for _, user := range approvals.ApprovedBy {
|
|
|
|
reviews = append(reviews, &base.Review{
|
Store the foreign ID of issues during migration (#18446)
Storing the foreign identifier of an imported issue in the database is a prerequisite to implement idempotent migrations or mirror for issues. It is a baby step towards mirroring that introduces a new table.
At the moment when an issue is created by the Gitea uploader, it fails if the issue already exists. The Gitea uploader could be modified so that, instead of failing, it looks up the database to find an existing issue. And if it does it would update the issue instead of creating a new one. However this is not currently possible because an information is missing from the database: the foreign identifier that uniquely represents the issue being migrated is not persisted. With this change, the foreign identifier is stored in the database and the Gitea uploader will then be able to run a query to figure out if a given issue being imported already exists.
The implementation of mirroring for issues, pull requests, releases, etc. can be done in three steps:
1. Store an identifier for the element being mirrored (issue, pull request...) in the database (this is the purpose of these changes)
2. Modify the Gitea uploader to be able to update an existing repository with all it contains (issues, pull request...) instead of failing if it exists
3. Optimize the Gitea uploader to speed up the updates, when possible.
The second step creates code that does not yet exist to enable idempotent migrations with the Gitea uploader. When a migration is done for the first time, the behavior is not changed. But when a migration is done for a repository that already exists, this new code is used to update it.
The third step can use the code created in the second step to optimize and speed up migrations. For instance, when a migration is resumed, an issue that has an update time that is not more recent can be skipped and only newly created issues or updated ones will be updated. Another example of optimization could be that a webhook notifies Gitea when an issue is updated. The code triggered by the webhook would download only this issue and call the code created in the second step to update the issue, as if it was in the process of an idempotent migration.
The ForeignReferences table is added to contain local and foreign ID pairs relative to a given repository. It can later be used for pull requests and other artifacts that can be mirrored. Although the foreign id could be added as a single field in issues or pull requests, it would need to be added to all tables that represent something that can be mirrored. Creating a new table makes for a simpler and more generic design. The drawback is that it requires an extra lookup to obtain the information. However, this extra information is only required during migration or mirroring and does not impact the way Gitea currently works.
The foreign identifier of an issue or pull request is similar to the identifier of an external user, which is stored in reactions, issues, etc. as OriginalPosterID and so on. The representation of a user is however different and the ability of users to link their account to an external user at a later time is also a logic that is different from what is involved in mirroring or migrations. For these reasons, despite some commonalities, it is unclear at this time how the two tables (foreign reference and external user) could be merged together.
The ForeignID field is extracted from the issue migration context so that it can be dumped in files with dump-repo and later restored via restore-repo.
The GetAllComments downloader method is introduced to simplify the implementation and not overload the Context for the purpose of pagination. It also clarifies in which context the comments are paginated and in which context they are not.
The Context interface is no longer useful for the purpose of retrieving the LocalID and ForeignID since they are now both available from the PullRequest and Issue struct. The Reviewable and Commentable interfaces replace and serve the same purpose.
The Context data member of PullRequest and Issue becomes a DownloaderContext to clarify that its purpose is not to support in memory operations while the current downloader is acting but is not otherwise persisted. It is, for instance, used by the GitLab downloader to store the IsMergeRequest boolean and sort out issues.
---
[source](https://lab.forgefriends.org/forgefriends/forgefriends/-/merge_requests/36)
Signed-off-by: Loïc Dachary <loic@dachary.org>
Co-authored-by: Loïc Dachary <loic@dachary.org>
3 years ago
|
|
|
IssueIndex: reviewable.GetLocalIndex(),
|
|
|
|
ReviewerID: int64(user.User.ID),
|
|
|
|
ReviewerName: user.User.Username,
|
|
|
|
CreatedAt: createdAt,
|
|
|
|
// All we get are approvals
|
|
|
|
State: base.ReviewStateApproved,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
return reviews, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (g *GitlabDownloader) awardsToReactions(awards []*gitlab.AwardEmoji) []*base.Reaction {
|
|
|
|
result := make([]*base.Reaction, 0, len(awards))
|
|
|
|
uniqCheck := make(map[string]struct{})
|
|
|
|
for _, award := range awards {
|
|
|
|
uid := fmt.Sprintf("%s%d", award.Name, award.User.ID)
|
|
|
|
if _, ok := uniqCheck[uid]; !ok {
|
|
|
|
result = append(result, &base.Reaction{
|
|
|
|
UserID: int64(award.User.ID),
|
|
|
|
UserName: award.User.Username,
|
|
|
|
Content: award.Name,
|
|
|
|
})
|
|
|
|
uniqCheck[uid] = struct{}{}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return result
|
|
|
|
}
|