2017-02-27 18:35:55 -07:00
|
|
|
// Copyright 2017 The Gitea Authors. All rights reserved.
|
2022-11-27 11:20:29 -07:00
|
|
|
// SPDX-License-Identifier: MIT
|
2017-02-27 18:35:55 -07:00
|
|
|
|
2022-06-13 03:37:59 -06:00
|
|
|
package issues_test
|
2017-02-27 18:35:55 -07:00
|
|
|
|
|
|
|
import (
|
2022-01-27 01:30:51 -07:00
|
|
|
"context"
|
2021-09-19 05:49:59 -06:00
|
|
|
"fmt"
|
2017-03-15 19:34:24 -06:00
|
|
|
"sort"
|
2021-09-19 05:49:59 -06:00
|
|
|
"sync"
|
2017-02-27 18:35:55 -07:00
|
|
|
"testing"
|
2017-07-26 19:20:38 -06:00
|
|
|
"time"
|
2017-02-27 18:35:55 -07:00
|
|
|
|
2021-09-19 05:49:59 -06:00
|
|
|
"code.gitea.io/gitea/models/db"
|
2022-04-08 03:11:15 -06:00
|
|
|
issues_model "code.gitea.io/gitea/models/issues"
|
2021-12-09 18:27:50 -07:00
|
|
|
repo_model "code.gitea.io/gitea/models/repo"
|
2021-11-12 07:36:47 -07:00
|
|
|
"code.gitea.io/gitea/models/unittest"
|
2021-11-24 02:49:20 -07:00
|
|
|
user_model "code.gitea.io/gitea/models/user"
|
2024-12-10 23:33:24 -07:00
|
|
|
"code.gitea.io/gitea/modules/optional"
|
2023-07-12 08:10:35 -06:00
|
|
|
"code.gitea.io/gitea/modules/setting"
|
2021-11-17 05:34:35 -07:00
|
|
|
|
2017-02-27 18:35:55 -07:00
|
|
|
"github.com/stretchr/testify/assert"
|
2022-04-25 08:06:24 -06:00
|
|
|
"xorm.io/builder"
|
2017-02-27 18:35:55 -07:00
|
|
|
)
|
|
|
|
|
|
|
|
func TestIssue_ReplaceLabels(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2017-02-27 18:35:55 -07:00
|
|
|
|
Scoped labels (#22585)
Add a new "exclusive" option per label. This makes it so that when the
label is named `scope/name`, no other label with the same `scope/`
prefix can be set on an issue.
The scope is determined by the last occurence of `/`, so for example
`scope/alpha/name` and `scope/beta/name` are considered to be in
different scopes and can coexist.
Exclusive scopes are not enforced by any database rules, however they
are enforced when editing labels at the models level, automatically
removing any existing labels in the same scope when either attaching a
new label or replacing all labels.
In menus use a circle instead of checkbox to indicate they function as
radio buttons per scope. Issue filtering by label ensures that only a
single scoped label is selected at a time. Clicking with alt key can be
used to remove a scoped label, both when editing individual issues and
batch editing.
Label rendering refactor for consistency and code simplification:
* Labels now consistently have the same shape, emojis and tooltips
everywhere. This includes the label list and label assignment menus.
* In label list, show description below label same as label menus.
* Don't use exactly black/white text colors to look a bit nicer.
* Simplify text color computation. There is no point computing luminance
in linear color space, as this is a perceptual problem and sRGB is
closer to perceptually linear.
* Increase height of label assignment menus to show more labels. Showing
only 3-4 labels at a time leads to a lot of scrolling.
* Render all labels with a new RenderLabel template helper function.
Label creation and editing in multiline modal menu:
* Change label creation to open a modal menu like label editing.
* Change menu layout to place name, description and colors on separate
lines.
* Don't color cancel button red in label editing modal menu.
* Align text to the left in model menu for better readability and
consistent with settings layout elsewhere.
Custom exclusive scoped label rendering:
* Display scoped label prefix and suffix with slightly darker and
lighter background color respectively, and a slanted edge between them
similar to the `/` symbol.
* In menus exclusive labels are grouped with a divider line.
---------
Co-authored-by: Yarden Shoham <hrsi88@gmail.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
2023-02-18 12:17:39 -07:00
|
|
|
testSuccess := func(issueID int64, labelIDs, expectedLabelIDs []int64) {
|
2022-08-15 20:22:25 -06:00
|
|
|
issue := unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{ID: issueID})
|
|
|
|
repo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: issue.RepoID})
|
|
|
|
doer := unittest.AssertExistsAndLoadBean(t, &user_model.User{ID: repo.OwnerID})
|
2017-02-27 18:35:55 -07:00
|
|
|
|
2022-06-13 03:37:59 -06:00
|
|
|
labels := make([]*issues_model.Label, len(labelIDs))
|
2017-02-27 18:35:55 -07:00
|
|
|
for i, labelID := range labelIDs {
|
2022-08-15 20:22:25 -06:00
|
|
|
labels[i] = unittest.AssertExistsAndLoadBean(t, &issues_model.Label{ID: labelID, RepoID: repo.ID})
|
2017-02-27 18:35:55 -07:00
|
|
|
}
|
2023-10-10 22:24:07 -06:00
|
|
|
assert.NoError(t, issues_model.ReplaceIssueLabels(db.DefaultContext, issue, labels, doer))
|
Scoped labels (#22585)
Add a new "exclusive" option per label. This makes it so that when the
label is named `scope/name`, no other label with the same `scope/`
prefix can be set on an issue.
The scope is determined by the last occurence of `/`, so for example
`scope/alpha/name` and `scope/beta/name` are considered to be in
different scopes and can coexist.
Exclusive scopes are not enforced by any database rules, however they
are enforced when editing labels at the models level, automatically
removing any existing labels in the same scope when either attaching a
new label or replacing all labels.
In menus use a circle instead of checkbox to indicate they function as
radio buttons per scope. Issue filtering by label ensures that only a
single scoped label is selected at a time. Clicking with alt key can be
used to remove a scoped label, both when editing individual issues and
batch editing.
Label rendering refactor for consistency and code simplification:
* Labels now consistently have the same shape, emojis and tooltips
everywhere. This includes the label list and label assignment menus.
* In label list, show description below label same as label menus.
* Don't use exactly black/white text colors to look a bit nicer.
* Simplify text color computation. There is no point computing luminance
in linear color space, as this is a perceptual problem and sRGB is
closer to perceptually linear.
* Increase height of label assignment menus to show more labels. Showing
only 3-4 labels at a time leads to a lot of scrolling.
* Render all labels with a new RenderLabel template helper function.
Label creation and editing in multiline modal menu:
* Change label creation to open a modal menu like label editing.
* Change menu layout to place name, description and colors on separate
lines.
* Don't color cancel button red in label editing modal menu.
* Align text to the left in model menu for better readability and
consistent with settings layout elsewhere.
Custom exclusive scoped label rendering:
* Display scoped label prefix and suffix with slightly darker and
lighter background color respectively, and a slanted edge between them
similar to the `/` symbol.
* In menus exclusive labels are grouped with a divider line.
---------
Co-authored-by: Yarden Shoham <hrsi88@gmail.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
2023-02-18 12:17:39 -07:00
|
|
|
unittest.AssertCount(t, &issues_model.IssueLabel{IssueID: issueID}, len(expectedLabelIDs))
|
|
|
|
for _, labelID := range expectedLabelIDs {
|
2022-06-13 03:37:59 -06:00
|
|
|
unittest.AssertExistsAndLoadBean(t, &issues_model.IssueLabel{IssueID: issueID, LabelID: labelID})
|
2017-02-27 18:35:55 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Scoped labels (#22585)
Add a new "exclusive" option per label. This makes it so that when the
label is named `scope/name`, no other label with the same `scope/`
prefix can be set on an issue.
The scope is determined by the last occurence of `/`, so for example
`scope/alpha/name` and `scope/beta/name` are considered to be in
different scopes and can coexist.
Exclusive scopes are not enforced by any database rules, however they
are enforced when editing labels at the models level, automatically
removing any existing labels in the same scope when either attaching a
new label or replacing all labels.
In menus use a circle instead of checkbox to indicate they function as
radio buttons per scope. Issue filtering by label ensures that only a
single scoped label is selected at a time. Clicking with alt key can be
used to remove a scoped label, both when editing individual issues and
batch editing.
Label rendering refactor for consistency and code simplification:
* Labels now consistently have the same shape, emojis and tooltips
everywhere. This includes the label list and label assignment menus.
* In label list, show description below label same as label menus.
* Don't use exactly black/white text colors to look a bit nicer.
* Simplify text color computation. There is no point computing luminance
in linear color space, as this is a perceptual problem and sRGB is
closer to perceptually linear.
* Increase height of label assignment menus to show more labels. Showing
only 3-4 labels at a time leads to a lot of scrolling.
* Render all labels with a new RenderLabel template helper function.
Label creation and editing in multiline modal menu:
* Change label creation to open a modal menu like label editing.
* Change menu layout to place name, description and colors on separate
lines.
* Don't color cancel button red in label editing modal menu.
* Align text to the left in model menu for better readability and
consistent with settings layout elsewhere.
Custom exclusive scoped label rendering:
* Display scoped label prefix and suffix with slightly darker and
lighter background color respectively, and a slanted edge between them
similar to the `/` symbol.
* In menus exclusive labels are grouped with a divider line.
---------
Co-authored-by: Yarden Shoham <hrsi88@gmail.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
2023-02-18 12:17:39 -07:00
|
|
|
testSuccess(1, []int64{2}, []int64{2})
|
|
|
|
testSuccess(1, []int64{1, 2}, []int64{1, 2})
|
|
|
|
testSuccess(1, []int64{}, []int64{})
|
|
|
|
|
|
|
|
// mutually exclusive scoped labels 7 and 8
|
|
|
|
testSuccess(18, []int64{6, 7}, []int64{6, 7})
|
|
|
|
testSuccess(18, []int64{7, 8}, []int64{8})
|
|
|
|
testSuccess(18, []int64{6, 8, 7}, []int64{6, 7})
|
2017-02-27 18:35:55 -07:00
|
|
|
}
|
2017-03-03 07:35:42 -07:00
|
|
|
|
2021-06-09 18:08:19 -06:00
|
|
|
func Test_GetIssueIDsByRepoID(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2021-06-09 18:08:19 -06:00
|
|
|
|
2022-06-13 03:37:59 -06:00
|
|
|
ids, err := issues_model.GetIssueIDsByRepoID(db.DefaultContext, 1)
|
2021-06-09 18:08:19 -06:00
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.Len(t, ids, 5)
|
|
|
|
}
|
|
|
|
|
2017-03-03 07:35:42 -07:00
|
|
|
func TestIssueAPIURL(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2022-08-15 20:22:25 -06:00
|
|
|
issue := unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{ID: 1})
|
2022-06-13 03:37:59 -06:00
|
|
|
err := issue.LoadAttributes(db.DefaultContext)
|
2017-03-03 07:35:42 -07:00
|
|
|
|
|
|
|
assert.NoError(t, err)
|
2023-10-03 04:30:41 -06:00
|
|
|
assert.Equal(t, "https://try.gitea.io/api/v1/repos/user2/repo1/issues/1", issue.APIURL(db.DefaultContext))
|
2017-03-03 07:35:42 -07:00
|
|
|
}
|
2017-03-14 19:10:35 -06:00
|
|
|
|
|
|
|
func TestGetIssuesByIDs(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2021-03-14 12:52:12 -06:00
|
|
|
testSuccess := func(expectedIssueIDs, nonExistentIssueIDs []int64) {
|
Refactor and enhance issue indexer to support both searching, filtering and paging (#26012)
Fix #24662.
Replace #24822 and #25708 (although it has been merged)
## Background
In the past, Gitea supported issue searching with a keyword and
conditions in a less efficient way. It worked by searching for issues
with the keyword and obtaining limited IDs (as it is heavy to get all)
on the indexer (bleve/elasticsearch/meilisearch), and then querying with
conditions on the database to find a subset of the found IDs. This is
why the results could be incomplete.
To solve this issue, we need to store all fields that could be used as
conditions in the indexer and support both keyword and additional
conditions when searching with the indexer.
## Major changes
- Redefine `IndexerData` to include all fields that could be used as
filter conditions.
- Refactor `Search(ctx context.Context, kw string, repoIDs []int64,
limit, start int, state string)` to `Search(ctx context.Context, options
*SearchOptions)`, so it supports more conditions now.
- Change the data type stored in `issueIndexerQueue`. Use
`IndexerMetadata` instead of `IndexerData` in case the data has been
updated while it is in the queue. This also reduces the storage size of
the queue.
- Enhance searching with Bleve/Elasticsearch/Meilisearch, make them
fully support `SearchOptions`. Also, update the data versions.
- Keep most logic of database indexer, but remove
`issues.SearchIssueIDsByKeyword` in `models` to avoid confusion where is
the entry point to search issues.
- Start a Meilisearch instance to test it in unit tests.
- Add unit tests with almost full coverage to test
Bleve/Elasticsearch/Meilisearch indexer.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2023-07-31 00:28:53 -06:00
|
|
|
issues, err := issues_model.GetIssuesByIDs(db.DefaultContext, append(expectedIssueIDs, nonExistentIssueIDs...), true)
|
2017-03-14 19:10:35 -06:00
|
|
|
assert.NoError(t, err)
|
|
|
|
actualIssueIDs := make([]int64, len(issues))
|
|
|
|
for i, issue := range issues {
|
|
|
|
actualIssueIDs[i] = issue.ID
|
|
|
|
}
|
|
|
|
assert.Equal(t, expectedIssueIDs, actualIssueIDs)
|
|
|
|
}
|
|
|
|
testSuccess([]int64{1, 2, 3}, []int64{})
|
2021-11-16 01:53:21 -07:00
|
|
|
testSuccess([]int64{1, 2, 3}, []int64{unittest.NonexistentID})
|
Refactor and enhance issue indexer to support both searching, filtering and paging (#26012)
Fix #24662.
Replace #24822 and #25708 (although it has been merged)
## Background
In the past, Gitea supported issue searching with a keyword and
conditions in a less efficient way. It worked by searching for issues
with the keyword and obtaining limited IDs (as it is heavy to get all)
on the indexer (bleve/elasticsearch/meilisearch), and then querying with
conditions on the database to find a subset of the found IDs. This is
why the results could be incomplete.
To solve this issue, we need to store all fields that could be used as
conditions in the indexer and support both keyword and additional
conditions when searching with the indexer.
## Major changes
- Redefine `IndexerData` to include all fields that could be used as
filter conditions.
- Refactor `Search(ctx context.Context, kw string, repoIDs []int64,
limit, start int, state string)` to `Search(ctx context.Context, options
*SearchOptions)`, so it supports more conditions now.
- Change the data type stored in `issueIndexerQueue`. Use
`IndexerMetadata` instead of `IndexerData` in case the data has been
updated while it is in the queue. This also reduces the storage size of
the queue.
- Enhance searching with Bleve/Elasticsearch/Meilisearch, make them
fully support `SearchOptions`. Also, update the data versions.
- Keep most logic of database indexer, but remove
`issues.SearchIssueIDsByKeyword` in `models` to avoid confusion where is
the entry point to search issues.
- Start a Meilisearch instance to test it in unit tests.
- Add unit tests with almost full coverage to test
Bleve/Elasticsearch/Meilisearch indexer.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2023-07-31 00:28:53 -06:00
|
|
|
testSuccess([]int64{3, 2, 1}, []int64{})
|
2017-03-14 19:10:35 -06:00
|
|
|
}
|
2017-03-15 19:34:24 -06:00
|
|
|
|
2020-02-28 01:16:41 -07:00
|
|
|
func TestGetParticipantIDsByIssue(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2017-03-15 19:34:24 -06:00
|
|
|
|
2017-06-04 11:39:08 -06:00
|
|
|
checkParticipants := func(issueID int64, userIDs []int) {
|
2022-06-13 03:37:59 -06:00
|
|
|
issue, err := issues_model.GetIssueByID(db.DefaultContext, issueID)
|
2020-02-28 01:16:41 -07:00
|
|
|
assert.NoError(t, err)
|
2022-06-13 03:37:59 -06:00
|
|
|
participants, err := issue.GetParticipantIDsByIssue(db.DefaultContext)
|
2017-03-15 19:34:24 -06:00
|
|
|
if assert.NoError(t, err) {
|
2017-06-04 11:39:08 -06:00
|
|
|
participantsIDs := make([]int, len(participants))
|
2020-02-28 01:16:41 -07:00
|
|
|
for i, uid := range participants {
|
|
|
|
participantsIDs[i] = int(uid)
|
2017-03-20 18:55:00 -06:00
|
|
|
}
|
2017-06-04 11:39:08 -06:00
|
|
|
sort.Ints(participantsIDs)
|
2017-03-15 19:34:24 -06:00
|
|
|
sort.Ints(userIDs)
|
2017-06-04 11:39:08 -06:00
|
|
|
assert.Equal(t, userIDs, participantsIDs)
|
2017-03-15 19:34:24 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// User 1 is issue1 poster (see fixtures/issue.yml)
|
|
|
|
// User 2 only labeled issue1 (see fixtures/comment.yml)
|
|
|
|
// Users 3 and 5 made actual comments (see fixtures/comment.yml)
|
2017-09-15 18:18:25 -06:00
|
|
|
// User 3 is inactive, thus not active participant
|
2020-02-28 01:16:41 -07:00
|
|
|
checkParticipants(1, []int{1, 5})
|
2017-03-15 19:34:24 -06:00
|
|
|
}
|
2017-07-26 01:16:45 -06:00
|
|
|
|
|
|
|
func TestIssue_ClearLabels(t *testing.T) {
|
2021-03-14 12:52:12 -06:00
|
|
|
tests := []struct {
|
2017-07-26 01:16:45 -06:00
|
|
|
issueID int64
|
|
|
|
doerID int64
|
|
|
|
}{
|
|
|
|
{1, 2}, // non-pull-request, has labels
|
|
|
|
{2, 2}, // pull-request, has labels
|
|
|
|
{3, 2}, // pull-request, has no labels
|
|
|
|
}
|
|
|
|
for _, test := range tests {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2022-08-15 20:22:25 -06:00
|
|
|
issue := unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{ID: test.issueID})
|
|
|
|
doer := unittest.AssertExistsAndLoadBean(t, &user_model.User{ID: test.doerID})
|
2023-10-10 22:24:07 -06:00
|
|
|
assert.NoError(t, issues_model.ClearIssueLabels(db.DefaultContext, issue, doer))
|
2022-06-13 03:37:59 -06:00
|
|
|
unittest.AssertNotExistsBean(t, &issues_model.IssueLabel{IssueID: test.issueID})
|
2017-07-26 01:16:45 -06:00
|
|
|
}
|
|
|
|
}
|
2017-07-26 19:20:38 -06:00
|
|
|
|
|
|
|
func TestUpdateIssueCols(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2022-08-15 20:22:25 -06:00
|
|
|
issue := unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{})
|
2017-07-26 19:20:38 -06:00
|
|
|
|
|
|
|
const newTitle = "New Title for unit test"
|
|
|
|
issue.Title = newTitle
|
|
|
|
|
|
|
|
prevContent := issue.Content
|
|
|
|
issue.Content = "This should have no effect"
|
|
|
|
|
|
|
|
now := time.Now().Unix()
|
2022-06-13 03:37:59 -06:00
|
|
|
assert.NoError(t, issues_model.UpdateIssueCols(db.DefaultContext, issue, "name"))
|
2017-07-26 19:20:38 -06:00
|
|
|
then := time.Now().Unix()
|
|
|
|
|
2022-08-15 20:22:25 -06:00
|
|
|
updatedIssue := unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{ID: issue.ID})
|
2017-07-26 19:20:38 -06:00
|
|
|
assert.EqualValues(t, newTitle, updatedIssue.Title)
|
|
|
|
assert.EqualValues(t, prevContent, updatedIssue.Content)
|
2021-11-16 01:53:21 -07:00
|
|
|
unittest.AssertInt64InRange(t, now, then, int64(updatedIssue.UpdatedUnix))
|
2017-07-26 19:20:38 -06:00
|
|
|
}
|
2017-12-25 16:25:16 -07:00
|
|
|
|
|
|
|
func TestIssues(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2017-12-25 16:25:16 -07:00
|
|
|
for _, test := range []struct {
|
2022-06-13 03:37:59 -06:00
|
|
|
Opts issues_model.IssuesOptions
|
2017-12-25 16:25:16 -07:00
|
|
|
ExpectedIssueIDs []int64
|
|
|
|
}{
|
|
|
|
{
|
2022-06-13 03:37:59 -06:00
|
|
|
issues_model.IssuesOptions{
|
2024-12-10 23:33:24 -07:00
|
|
|
AssigneeID: optional.Some(int64(1)),
|
2017-12-25 16:25:16 -07:00
|
|
|
SortType: "oldest",
|
|
|
|
},
|
|
|
|
[]int64{1, 6},
|
|
|
|
},
|
|
|
|
{
|
2022-06-13 03:37:59 -06:00
|
|
|
issues_model.IssuesOptions{
|
2022-04-25 08:06:24 -06:00
|
|
|
RepoCond: builder.In("repo_id", 1, 3),
|
2017-12-25 16:25:16 -07:00
|
|
|
SortType: "oldest",
|
Refactor and enhance issue indexer to support both searching, filtering and paging (#26012)
Fix #24662.
Replace #24822 and #25708 (although it has been merged)
## Background
In the past, Gitea supported issue searching with a keyword and
conditions in a less efficient way. It worked by searching for issues
with the keyword and obtaining limited IDs (as it is heavy to get all)
on the indexer (bleve/elasticsearch/meilisearch), and then querying with
conditions on the database to find a subset of the found IDs. This is
why the results could be incomplete.
To solve this issue, we need to store all fields that could be used as
conditions in the indexer and support both keyword and additional
conditions when searching with the indexer.
## Major changes
- Redefine `IndexerData` to include all fields that could be used as
filter conditions.
- Refactor `Search(ctx context.Context, kw string, repoIDs []int64,
limit, start int, state string)` to `Search(ctx context.Context, options
*SearchOptions)`, so it supports more conditions now.
- Change the data type stored in `issueIndexerQueue`. Use
`IndexerMetadata` instead of `IndexerData` in case the data has been
updated while it is in the queue. This also reduces the storage size of
the queue.
- Enhance searching with Bleve/Elasticsearch/Meilisearch, make them
fully support `SearchOptions`. Also, update the data versions.
- Keep most logic of database indexer, but remove
`issues.SearchIssueIDsByKeyword` in `models` to avoid confusion where is
the entry point to search issues.
- Start a Meilisearch instance to test it in unit tests.
- Add unit tests with almost full coverage to test
Bleve/Elasticsearch/Meilisearch indexer.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2023-07-31 00:28:53 -06:00
|
|
|
Paginator: &db.ListOptions{
|
2020-01-24 12:00:29 -07:00
|
|
|
Page: 1,
|
|
|
|
PageSize: 4,
|
|
|
|
},
|
2017-12-25 16:25:16 -07:00
|
|
|
},
|
|
|
|
[]int64{1, 2, 3, 5},
|
|
|
|
},
|
|
|
|
{
|
2022-06-13 03:37:59 -06:00
|
|
|
issues_model.IssuesOptions{
|
2019-01-22 21:10:38 -07:00
|
|
|
LabelIDs: []int64{1},
|
Refactor and enhance issue indexer to support both searching, filtering and paging (#26012)
Fix #24662.
Replace #24822 and #25708 (although it has been merged)
## Background
In the past, Gitea supported issue searching with a keyword and
conditions in a less efficient way. It worked by searching for issues
with the keyword and obtaining limited IDs (as it is heavy to get all)
on the indexer (bleve/elasticsearch/meilisearch), and then querying with
conditions on the database to find a subset of the found IDs. This is
why the results could be incomplete.
To solve this issue, we need to store all fields that could be used as
conditions in the indexer and support both keyword and additional
conditions when searching with the indexer.
## Major changes
- Redefine `IndexerData` to include all fields that could be used as
filter conditions.
- Refactor `Search(ctx context.Context, kw string, repoIDs []int64,
limit, start int, state string)` to `Search(ctx context.Context, options
*SearchOptions)`, so it supports more conditions now.
- Change the data type stored in `issueIndexerQueue`. Use
`IndexerMetadata` instead of `IndexerData` in case the data has been
updated while it is in the queue. This also reduces the storage size of
the queue.
- Enhance searching with Bleve/Elasticsearch/Meilisearch, make them
fully support `SearchOptions`. Also, update the data versions.
- Keep most logic of database indexer, but remove
`issues.SearchIssueIDsByKeyword` in `models` to avoid confusion where is
the entry point to search issues.
- Start a Meilisearch instance to test it in unit tests.
- Add unit tests with almost full coverage to test
Bleve/Elasticsearch/Meilisearch indexer.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2023-07-31 00:28:53 -06:00
|
|
|
Paginator: &db.ListOptions{
|
2020-01-24 12:00:29 -07:00
|
|
|
Page: 1,
|
|
|
|
PageSize: 4,
|
|
|
|
},
|
2017-12-25 16:25:16 -07:00
|
|
|
},
|
2019-01-22 21:10:38 -07:00
|
|
|
[]int64{2, 1},
|
|
|
|
},
|
|
|
|
{
|
2022-06-13 03:37:59 -06:00
|
|
|
issues_model.IssuesOptions{
|
2019-01-22 21:10:38 -07:00
|
|
|
LabelIDs: []int64{1, 2},
|
Refactor and enhance issue indexer to support both searching, filtering and paging (#26012)
Fix #24662.
Replace #24822 and #25708 (although it has been merged)
## Background
In the past, Gitea supported issue searching with a keyword and
conditions in a less efficient way. It worked by searching for issues
with the keyword and obtaining limited IDs (as it is heavy to get all)
on the indexer (bleve/elasticsearch/meilisearch), and then querying with
conditions on the database to find a subset of the found IDs. This is
why the results could be incomplete.
To solve this issue, we need to store all fields that could be used as
conditions in the indexer and support both keyword and additional
conditions when searching with the indexer.
## Major changes
- Redefine `IndexerData` to include all fields that could be used as
filter conditions.
- Refactor `Search(ctx context.Context, kw string, repoIDs []int64,
limit, start int, state string)` to `Search(ctx context.Context, options
*SearchOptions)`, so it supports more conditions now.
- Change the data type stored in `issueIndexerQueue`. Use
`IndexerMetadata` instead of `IndexerData` in case the data has been
updated while it is in the queue. This also reduces the storage size of
the queue.
- Enhance searching with Bleve/Elasticsearch/Meilisearch, make them
fully support `SearchOptions`. Also, update the data versions.
- Keep most logic of database indexer, but remove
`issues.SearchIssueIDsByKeyword` in `models` to avoid confusion where is
the entry point to search issues.
- Start a Meilisearch instance to test it in unit tests.
- Add unit tests with almost full coverage to test
Bleve/Elasticsearch/Meilisearch indexer.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2023-07-31 00:28:53 -06:00
|
|
|
Paginator: &db.ListOptions{
|
2020-01-24 12:00:29 -07:00
|
|
|
Page: 1,
|
|
|
|
PageSize: 4,
|
|
|
|
},
|
2019-01-22 21:10:38 -07:00
|
|
|
},
|
|
|
|
[]int64{}, // issues with **both** label 1 and 2, none of these issues matches, TODO: add more tests
|
2017-12-25 16:25:16 -07:00
|
|
|
},
|
2023-10-19 08:08:31 -06:00
|
|
|
{
|
|
|
|
issues_model.IssuesOptions{
|
|
|
|
MilestoneIDs: []int64{1},
|
|
|
|
},
|
|
|
|
[]int64{2},
|
|
|
|
},
|
2017-12-25 16:25:16 -07:00
|
|
|
} {
|
2022-11-19 01:12:33 -07:00
|
|
|
issues, err := issues_model.Issues(db.DefaultContext, &test.Opts)
|
2017-12-25 16:25:16 -07:00
|
|
|
assert.NoError(t, err)
|
|
|
|
if assert.Len(t, issues, len(test.ExpectedIssueIDs)) {
|
|
|
|
for i, issue := range issues {
|
|
|
|
assert.EqualValues(t, test.ExpectedIssueIDs[i], issue.ID)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-28 23:58:47 -06:00
|
|
|
func TestIssue_loadTotalTimes(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2022-06-13 03:37:59 -06:00
|
|
|
ms, err := issues_model.GetIssueByID(db.DefaultContext, 2)
|
2018-04-28 23:58:47 -06:00
|
|
|
assert.NoError(t, err)
|
2022-06-13 03:37:59 -06:00
|
|
|
assert.NoError(t, ms.LoadTotalTimes(db.DefaultContext))
|
2019-12-27 13:30:58 -07:00
|
|
|
assert.Equal(t, int64(3682), ms.TotalTrackedTime)
|
2018-04-28 23:58:47 -06:00
|
|
|
}
|
2019-02-20 22:01:28 -07:00
|
|
|
|
2022-06-13 03:37:59 -06:00
|
|
|
func testInsertIssue(t *testing.T, title, content string, expectIndex int64) *issues_model.Issue {
|
|
|
|
var newIssue issues_model.Issue
|
2021-06-13 20:22:55 -06:00
|
|
|
t.Run(title, func(t *testing.T) {
|
2022-08-15 20:22:25 -06:00
|
|
|
repo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: 1})
|
|
|
|
user := unittest.AssertExistsAndLoadBean(t, &user_model.User{ID: 2})
|
2021-06-13 20:22:55 -06:00
|
|
|
|
2022-06-13 03:37:59 -06:00
|
|
|
issue := issues_model.Issue{
|
2021-06-13 20:22:55 -06:00
|
|
|
RepoID: repo.ID,
|
|
|
|
PosterID: user.ID,
|
2021-10-23 08:47:38 -06:00
|
|
|
Poster: user,
|
2021-06-13 20:22:55 -06:00
|
|
|
Title: title,
|
|
|
|
Content: content,
|
|
|
|
}
|
2023-09-29 06:12:54 -06:00
|
|
|
err := issues_model.NewIssue(db.DefaultContext, repo, &issue, nil, nil)
|
2021-06-13 20:22:55 -06:00
|
|
|
assert.NoError(t, err)
|
2019-09-29 06:52:39 -06:00
|
|
|
|
2021-09-23 09:45:36 -06:00
|
|
|
has, err := db.GetEngine(db.DefaultContext).ID(issue.ID).Get(&newIssue)
|
2021-06-13 20:22:55 -06:00
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.True(t, has)
|
|
|
|
assert.EqualValues(t, issue.Title, newIssue.Title)
|
|
|
|
assert.EqualValues(t, issue.Content, newIssue.Content)
|
|
|
|
if expectIndex > 0 {
|
|
|
|
assert.EqualValues(t, expectIndex, newIssue.Index)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
return &newIssue
|
2019-09-29 06:52:39 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestIssue_InsertIssue(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2019-09-29 06:52:39 -06:00
|
|
|
|
2021-06-13 20:22:55 -06:00
|
|
|
// there are 5 issues and max index is 5 on repository 1, so this one should 6
|
|
|
|
issue := testInsertIssue(t, "my issue1", "special issue's comments?", 6)
|
2023-12-25 13:25:29 -07:00
|
|
|
_, err := db.DeleteByID[issues_model.Issue](db.DefaultContext, issue.ID)
|
2021-06-13 20:22:55 -06:00
|
|
|
assert.NoError(t, err)
|
|
|
|
|
|
|
|
issue = testInsertIssue(t, `my issue2, this is my son's love \n \r \ `, "special issue's '' comments?", 7)
|
2023-12-25 13:25:29 -07:00
|
|
|
_, err = db.DeleteByID[issues_model.Issue](db.DefaultContext, issue.ID)
|
2021-06-13 20:22:55 -06:00
|
|
|
assert.NoError(t, err)
|
2019-09-29 06:52:39 -06:00
|
|
|
}
|
2019-10-10 10:45:11 -06:00
|
|
|
|
|
|
|
func TestIssue_ResolveMentions(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2019-10-10 10:45:11 -06:00
|
|
|
|
|
|
|
testSuccess := func(owner, repo, doer string, mentions []string, expected []int64) {
|
2022-08-15 20:22:25 -06:00
|
|
|
o := unittest.AssertExistsAndLoadBean(t, &user_model.User{LowerName: owner})
|
|
|
|
r := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{OwnerID: o.ID, LowerName: repo})
|
2022-06-13 03:37:59 -06:00
|
|
|
issue := &issues_model.Issue{RepoID: r.ID}
|
2022-08-15 20:22:25 -06:00
|
|
|
d := unittest.AssertExistsAndLoadBean(t, &user_model.User{LowerName: doer})
|
2022-06-13 03:37:59 -06:00
|
|
|
resolved, err := issues_model.ResolveIssueMentionsByVisibility(db.DefaultContext, issue, d, mentions)
|
2019-10-10 10:45:11 -06:00
|
|
|
assert.NoError(t, err)
|
|
|
|
ids := make([]int64, len(resolved))
|
|
|
|
for i, user := range resolved {
|
|
|
|
ids[i] = user.ID
|
|
|
|
}
|
|
|
|
sort.Slice(ids, func(i, j int) bool { return ids[i] < ids[j] })
|
|
|
|
assert.EqualValues(t, expected, ids)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Public repo, existing user
|
|
|
|
testSuccess("user2", "repo1", "user1", []string{"user5"}, []int64{5})
|
|
|
|
// Public repo, non-existing user
|
|
|
|
testSuccess("user2", "repo1", "user1", []string{"nonexisting"}, []int64{})
|
|
|
|
// Public repo, doer
|
|
|
|
testSuccess("user2", "repo1", "user1", []string{"user1"}, []int64{})
|
|
|
|
// Private repo, team member
|
2023-09-13 20:59:53 -06:00
|
|
|
testSuccess("org17", "big_test_private_4", "user20", []string{"user2"}, []int64{2})
|
2019-10-10 10:45:11 -06:00
|
|
|
// Private repo, not a team member
|
2023-09-13 20:59:53 -06:00
|
|
|
testSuccess("org17", "big_test_private_4", "user20", []string{"user5"}, []int64{})
|
2019-10-10 10:45:11 -06:00
|
|
|
// Private repo, whole team
|
2023-09-13 20:59:53 -06:00
|
|
|
testSuccess("org17", "big_test_private_4", "user15", []string{"org17/owners"}, []int64{18})
|
2019-10-10 10:45:11 -06:00
|
|
|
}
|
2021-09-19 05:49:59 -06:00
|
|
|
|
|
|
|
func TestResourceIndex(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2021-09-19 05:49:59 -06:00
|
|
|
|
|
|
|
var wg sync.WaitGroup
|
|
|
|
for i := 0; i < 100; i++ {
|
|
|
|
wg.Add(1)
|
|
|
|
go func(i int) {
|
|
|
|
testInsertIssue(t, fmt.Sprintf("issue %d", i+1), "my issue", 0)
|
|
|
|
wg.Done()
|
|
|
|
}(i)
|
|
|
|
}
|
|
|
|
wg.Wait()
|
|
|
|
}
|
2021-11-08 14:14:46 -07:00
|
|
|
|
|
|
|
func TestCorrectIssueStats(t *testing.T) {
|
2021-11-12 07:36:47 -07:00
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2021-11-08 14:14:46 -07:00
|
|
|
|
|
|
|
// Because the condition is to have chunked database look-ups,
|
|
|
|
// We have to more issues than `maxQueryParameters`, we will insert.
|
|
|
|
// maxQueryParameters + 10 issues into the testDatabase.
|
|
|
|
// Each new issues will have a constant description "Bugs are nasty"
|
|
|
|
// Which will be used later on.
|
|
|
|
|
2022-06-13 03:37:59 -06:00
|
|
|
issueAmount := issues_model.MaxQueryParameters + 10
|
2021-11-08 14:14:46 -07:00
|
|
|
|
|
|
|
var wg sync.WaitGroup
|
|
|
|
for i := 0; i < issueAmount; i++ {
|
|
|
|
wg.Add(1)
|
|
|
|
go func(i int) {
|
|
|
|
testInsertIssue(t, fmt.Sprintf("Issue %d", i+1), "Bugs are nasty", 0)
|
|
|
|
wg.Done()
|
|
|
|
}(i)
|
|
|
|
}
|
|
|
|
wg.Wait()
|
|
|
|
|
|
|
|
// Now we will get all issueID's that match the "Bugs are nasty" query.
|
Refactor and enhance issue indexer to support both searching, filtering and paging (#26012)
Fix #24662.
Replace #24822 and #25708 (although it has been merged)
## Background
In the past, Gitea supported issue searching with a keyword and
conditions in a less efficient way. It worked by searching for issues
with the keyword and obtaining limited IDs (as it is heavy to get all)
on the indexer (bleve/elasticsearch/meilisearch), and then querying with
conditions on the database to find a subset of the found IDs. This is
why the results could be incomplete.
To solve this issue, we need to store all fields that could be used as
conditions in the indexer and support both keyword and additional
conditions when searching with the indexer.
## Major changes
- Redefine `IndexerData` to include all fields that could be used as
filter conditions.
- Refactor `Search(ctx context.Context, kw string, repoIDs []int64,
limit, start int, state string)` to `Search(ctx context.Context, options
*SearchOptions)`, so it supports more conditions now.
- Change the data type stored in `issueIndexerQueue`. Use
`IndexerMetadata` instead of `IndexerData` in case the data has been
updated while it is in the queue. This also reduces the storage size of
the queue.
- Enhance searching with Bleve/Elasticsearch/Meilisearch, make them
fully support `SearchOptions`. Also, update the data versions.
- Keep most logic of database indexer, but remove
`issues.SearchIssueIDsByKeyword` in `models` to avoid confusion where is
the entry point to search issues.
- Start a Meilisearch instance to test it in unit tests.
- Add unit tests with almost full coverage to test
Bleve/Elasticsearch/Meilisearch indexer.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2023-07-31 00:28:53 -06:00
|
|
|
issues, err := issues_model.Issues(context.TODO(), &issues_model.IssuesOptions{
|
|
|
|
Paginator: &db.ListOptions{
|
|
|
|
PageSize: issueAmount,
|
|
|
|
},
|
|
|
|
RepoIDs: []int64{1},
|
|
|
|
})
|
|
|
|
total := int64(len(issues))
|
|
|
|
var ids []int64
|
|
|
|
for _, issue := range issues {
|
|
|
|
if issue.Content == "Bugs are nasty" {
|
|
|
|
ids = append(ids, issue.ID)
|
|
|
|
}
|
|
|
|
}
|
2021-11-08 14:14:46 -07:00
|
|
|
|
|
|
|
// Just to be sure.
|
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.EqualValues(t, issueAmount, total)
|
|
|
|
|
|
|
|
// Now we will call the GetIssueStats with these IDs and if working,
|
|
|
|
// get the correct stats back.
|
2023-09-25 07:17:37 -06:00
|
|
|
issueStats, err := issues_model.GetIssueStats(db.DefaultContext, &issues_model.IssuesOptions{
|
2023-05-19 08:17:48 -06:00
|
|
|
RepoIDs: []int64{1},
|
2021-11-08 14:14:46 -07:00
|
|
|
IssueIDs: ids,
|
|
|
|
})
|
|
|
|
|
|
|
|
// Now check the values.
|
|
|
|
assert.NoError(t, err)
|
|
|
|
assert.EqualValues(t, issueStats.OpenCount, issueAmount)
|
|
|
|
}
|
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>
2022-03-17 11:08:35 -06:00
|
|
|
|
2022-04-08 03:11:15 -06:00
|
|
|
func TestMilestoneList_LoadTotalTrackedTimes(t *testing.T) {
|
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
|
|
|
miles := issues_model.MilestoneList{
|
2022-08-15 20:22:25 -06:00
|
|
|
unittest.AssertExistsAndLoadBean(t, &issues_model.Milestone{ID: 1}),
|
2022-04-08 03:11:15 -06:00
|
|
|
}
|
|
|
|
|
2023-09-16 08:39:12 -06:00
|
|
|
assert.NoError(t, miles.LoadTotalTrackedTimes(db.DefaultContext))
|
2022-04-08 03:11:15 -06:00
|
|
|
|
|
|
|
assert.Equal(t, int64(3682), miles[0].TotalTrackedTime)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestLoadTotalTrackedTime(t *testing.T) {
|
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2022-08-15 20:22:25 -06:00
|
|
|
milestone := unittest.AssertExistsAndLoadBean(t, &issues_model.Milestone{ID: 1})
|
2022-04-08 03:11:15 -06:00
|
|
|
|
2023-09-16 08:39:12 -06:00
|
|
|
assert.NoError(t, milestone.LoadTotalTrackedTime(db.DefaultContext))
|
2022-04-08 03:11:15 -06:00
|
|
|
|
|
|
|
assert.Equal(t, int64(3682), milestone.TotalTrackedTime)
|
|
|
|
}
|
2022-05-02 07:35:45 -06:00
|
|
|
|
|
|
|
func TestCountIssues(t *testing.T) {
|
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
2022-11-19 01:12:33 -07:00
|
|
|
count, err := issues_model.CountIssues(db.DefaultContext, &issues_model.IssuesOptions{})
|
2022-05-02 07:35:45 -06:00
|
|
|
assert.NoError(t, err)
|
2024-02-24 05:38:43 -07:00
|
|
|
assert.EqualValues(t, 22, count)
|
2022-05-02 07:35:45 -06:00
|
|
|
}
|
2023-07-12 08:10:35 -06:00
|
|
|
|
|
|
|
func TestIssueLoadAttributes(t *testing.T) {
|
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
|
|
|
setting.Service.EnableTimetracking = true
|
|
|
|
|
|
|
|
issueList := issues_model.IssueList{
|
|
|
|
unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{ID: 1}),
|
|
|
|
unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{ID: 4}),
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, issue := range issueList {
|
|
|
|
assert.NoError(t, issue.LoadAttributes(db.DefaultContext))
|
|
|
|
assert.EqualValues(t, issue.RepoID, issue.Repo.ID)
|
|
|
|
for _, label := range issue.Labels {
|
|
|
|
assert.EqualValues(t, issue.RepoID, label.RepoID)
|
|
|
|
unittest.AssertExistsAndLoadBean(t, &issues_model.IssueLabel{IssueID: issue.ID, LabelID: label.ID})
|
|
|
|
}
|
|
|
|
if issue.PosterID > 0 {
|
|
|
|
assert.EqualValues(t, issue.PosterID, issue.Poster.ID)
|
|
|
|
}
|
|
|
|
if issue.AssigneeID > 0 {
|
|
|
|
assert.EqualValues(t, issue.AssigneeID, issue.Assignee.ID)
|
|
|
|
}
|
|
|
|
if issue.MilestoneID > 0 {
|
|
|
|
assert.EqualValues(t, issue.MilestoneID, issue.Milestone.ID)
|
|
|
|
}
|
|
|
|
if issue.IsPull {
|
|
|
|
assert.EqualValues(t, issue.ID, issue.PullRequest.IssueID)
|
|
|
|
}
|
|
|
|
for _, attachment := range issue.Attachments {
|
|
|
|
assert.EqualValues(t, issue.ID, attachment.IssueID)
|
|
|
|
}
|
|
|
|
for _, comment := range issue.Comments {
|
|
|
|
assert.EqualValues(t, issue.ID, comment.IssueID)
|
|
|
|
}
|
|
|
|
if issue.ID == int64(1) {
|
|
|
|
assert.Equal(t, int64(400), issue.TotalTrackedTime)
|
|
|
|
assert.NotNil(t, issue.Project)
|
|
|
|
assert.Equal(t, int64(1), issue.Project.ID)
|
|
|
|
} else {
|
|
|
|
assert.Nil(t, issue.Project)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2023-09-08 15:09:23 -06:00
|
|
|
|
|
|
|
func assertCreateIssues(t *testing.T, isPull bool) {
|
|
|
|
assert.NoError(t, unittest.PrepareTestDatabase())
|
|
|
|
reponame := "repo1"
|
|
|
|
repo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{Name: reponame})
|
|
|
|
owner := unittest.AssertExistsAndLoadBean(t, &user_model.User{ID: repo.OwnerID})
|
|
|
|
label := unittest.AssertExistsAndLoadBean(t, &issues_model.Label{ID: 1})
|
|
|
|
milestone := unittest.AssertExistsAndLoadBean(t, &issues_model.Milestone{ID: 1})
|
|
|
|
assert.EqualValues(t, milestone.ID, 1)
|
|
|
|
reaction := &issues_model.Reaction{
|
|
|
|
Type: "heart",
|
|
|
|
UserID: owner.ID,
|
|
|
|
}
|
|
|
|
|
|
|
|
title := "issuetitle1"
|
|
|
|
is := &issues_model.Issue{
|
|
|
|
RepoID: repo.ID,
|
|
|
|
MilestoneID: milestone.ID,
|
|
|
|
Repo: repo,
|
|
|
|
Title: title,
|
|
|
|
Content: "issuecontent1",
|
|
|
|
IsPull: isPull,
|
|
|
|
PosterID: owner.ID,
|
|
|
|
Poster: owner,
|
|
|
|
IsClosed: true,
|
|
|
|
Labels: []*issues_model.Label{label},
|
|
|
|
Reactions: []*issues_model.Reaction{reaction},
|
|
|
|
}
|
2023-10-03 04:30:41 -06:00
|
|
|
err := issues_model.InsertIssues(db.DefaultContext, is)
|
2023-09-08 15:09:23 -06:00
|
|
|
assert.NoError(t, err)
|
|
|
|
|
|
|
|
i := unittest.AssertExistsAndLoadBean(t, &issues_model.Issue{Title: title})
|
|
|
|
unittest.AssertExistsAndLoadBean(t, &issues_model.Reaction{Type: "heart", UserID: owner.ID, IssueID: i.ID})
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestMigrate_CreateIssuesIsPullFalse(t *testing.T) {
|
|
|
|
assertCreateIssues(t, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestMigrate_CreateIssuesIsPullTrue(t *testing.T) {
|
|
|
|
assertCreateIssues(t, true)
|
|
|
|
}
|