Provide an API to set generic Pull-Request sidebar content #10546

New Issue

GiteaMirror · 2025-11-02T09:10:54-06:00

GiteaMirror commented

2025-11-02 09:10:54 -06:00

Originally created by @silverwind on GitHub (Mar 29, 2023).

Feature Description

It'd be nice if we could offer a API where third-party integrations like code coverage could create sidebar content into a PR, like for example coverage.

I could see it accepting something like

{
  "title": "CodeCov Coverage",
  "value": "55.32% (+0.15%)"
  "link": "https://codecov.example.com/pr-1234",
  "details": "more verbose markdown content..."
}

details and maybe value could accept Markdown. details content could be used to display a popup on mouseover that shows detailed content.

Originally created by @silverwind on GitHub (Mar 29, 2023). ### Feature Description It'd be nice if we could offer a API where third-party integrations like code coverage could create sidebar content into a PR, like for example coverage. I could see it accepting something like ```json { "title": "CodeCov Coverage", "value": "55.32% (+0.15%)" "link": "https://codecov.example.com/pr-1234", "details": "more verbose markdown content..." } ``` `details` and maybe `value` could accept Markdown. `details` content could be used to display a popup on mouseover that shows detailed content. Related: https://app.codecov.io/gh/feedback/p/support-gitea-scm https://github.com/go-gitea/gitea/issues/23746#issuecomment-1487308032

GiteaMirror added the topic/api type/proposal type/feature modifies/api labels 2025-11-02 09:10:54 -06:00

GiteaMirror closed this issue

2025-11-02 09:10:54 -06:00

GiteaMirror commented

2025-11-02 09:10:55 -06:00

@a1012112796 commented on GitHub (Mar 29, 2023):

looks check run feature in github is also good: https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-checks?apiVersion=2022-11-28

@a1012112796 commented on GitHub (Mar 29, 2023): looks `check run` feature in github is also good: https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-checks?apiVersion=2022-11-28

GiteaMirror commented

2025-11-02 09:10:55 -06:00

@jpraet commented on GitHub (Mar 29, 2023):

For this example use case about reporting test coverage of a PR, isn't commit status suited for that?

https://try.gitea.io/api/swagger#/repository/repoCreateStatus

@jpraet commented on GitHub (Mar 29, 2023): For this example use case about reporting test coverage of a PR, isn't commit status suited for that? https://try.gitea.io/api/swagger#/repository/repoCreateStatus

GiteaMirror commented

2025-11-02 09:10:55 -06:00

@silverwind commented on GitHub (Mar 29, 2023):

For this example use case about reporting test coverage of a PR, isn't commit status suited for that?

I think it's insufficient. It can only show success/error/warning etc, which is fine for cases where you want strict coverage, e.g. only success a PR if coverage increases. But for detailed reporting like CodeCov does as comments currently on GitHub, it's not enough.

@silverwind commented on GitHub (Mar 29, 2023): > For this example use case about reporting test coverage of a PR, isn't commit status suited for that? I think it's insufficient. It can only show success/error/warning etc, which is fine for cases where you want strict coverage, e.g. only success a PR if coverage increases. But for detailed reporting like CodeCov does as comments currently on GitHub, it's not enough.

GiteaMirror commented

2025-11-02 09:10:55 -06:00

@lunny commented on GitHub (Mar 30, 2023):

We need an standard API to store the coverage stats results. We can have a summary in the sidebar of pull request. And even more, we can display every file's coverage in pull request file view or commit file view.

@lunny commented on GitHub (Mar 30, 2023): We need an standard API to store the coverage stats results. We can have a summary in the sidebar of pull request. And even more, we can display every file's coverage in pull request file view or commit file view.

GiteaMirror commented

2025-11-02 09:10:55 -06:00

@silverwind commented on GitHub (Mar 30, 2023):

It could be generalized as "PR Metadata" and "PR file metadata" on the API. Thought I guess if we want to integrate deeply and show progress bars and such, there is no way around specifically supporting the coverage use case with specific APIs tailored to it.

@silverwind commented on GitHub (Mar 30, 2023): It could be generalized as "PR Metadata" and "PR file metadata" on the API. Thought I guess if we want to integrate deeply and show progress bars and such, there is no way around specifically supporting the coverage use case with specific APIs tailored to it.

GiteaMirror commented

2025-11-02 09:10:55 -06:00

@lunny commented on GitHub (Mar 30, 2023):

It could be generalized as "PR Metadata" and "PR file metadata" on the API. Thought I guess if we want to integrate deeply and show progress bars and such, there is no way around specifically supporting the coverage use case with specific APIs tailored to it.

Just like commit status API, it will stick owner_name/repo_name and commit SHA, but not associated with a special PR. Because you don't know which model users will use with Gitea.

@lunny commented on GitHub (Mar 30, 2023): > It could be generalized as "PR Metadata" and "PR file metadata" on the API. Thought I guess if we want to integrate deeply and show progress bars and such, there is no way around specifically supporting the coverage use case with specific APIs tailored to it. Just like commit status API, it will stick owner_name/repo_name and commit SHA, but not associated with a special PR. Because you don't know which model users will use with Gitea.

GiteaMirror commented

2025-11-02 09:10:56 -06:00

@a1012112796 commented on GitHub (Mar 31, 2023):

look the action also need it, ref: https://github.com/go-gitea/gitea/issues/23722 https://github.com/go-gitea/gitea/issues/23721

@a1012112796 commented on GitHub (Mar 31, 2023): look the action also need it, ref: https://github.com/go-gitea/gitea/issues/23722 https://github.com/go-gitea/gitea/issues/23721

GiteaMirror commented

2025-11-02 09:10:56 -06:00

@a1012112796 commented on GitHub (Mar 31, 2023):

I think the checks run feature in github is a good solution for this issue, looks it's Upgraded commit status. the difference betwen check run and commit status :

in my view, looks check run = commit status + code review

some tips about do it:

github api document: https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28
wonder whether create a new table named as CheckRun or just upgrade the CommitStatus struct
in github's document description, it bound with App feature, but in fact, looks it bound with Action also ...

To show it on ui, maybe we can reuse commit status and code comment ui
checkRun db struct in my view:

type ChekRun struct {
	ID         int64                  `xorm:"pk autoincr"`
	RepoID     int64                  `xorm:"INDEX UNIQUE(repo_sha_index)"`
	Repo       *repo_model.Repository `xorm:"-"`
	State      int64                  // difference with `CommitStatus`
	Conclusion int64                  // difference with `CommitStatus`

	SHA       string           `xorm:"VARCHAR(64) NOT NULL INDEX UNIQUE(repo_sha_index)"`
	TargetURL string           `xorm:"TEXT"`
	NameHash  string           `xorm:"char(40) index"`
	Name      string           `xorm:"TEXT"`
	Creator   *user_model.User `xorm:"-"`
	CreatorID int64

	StartAt     timeutil.TimeStamp // difference with `CommitStatus`
	CompletedAt timeutil.TimeStamp // difference with `CommitStatus`

	OutPut  *ChekRunOutPut  `xorm:"-"` // difference with `CommitStatus`
	Actions []ChekRunAction `xorm:"-"` // difference with `CommitStatus`

	CreatedUnix timeutil.TimeStamp `xorm:"INDEX created"`
	UpdatedUnix timeutil.TimeStamp `xorm:"INDEX updated"`
}

type ChekRunAnnotation struct {
	Path            string
	StartLine       int64
	EndLine         int64
	StartColumn     int64
	EndColumn       int64
	AnnotationLevel string
	Message         string
	Title           string
	RawDetails      string
}

type ChekRunOutPut struct {
	ID          int64 `xorm:"pk autoincr"`
	ChekcRunID  int64 `xorm:"INDEX"`
	Title       string
	Summary     string
	Text        string
	Annotations []ChekRunAnnotation `xorm:"JSON"`
}

type ChekRunAction struct {
	ID          int64 `xorm:"pk autoincr"`
	ChekcRunID  int64 `xorm:"INDEX"`
	Label       string
	Description string
	Identifier  string
	Url         string
}

@a1012112796 commented on GitHub (Mar 31, 2023): I think the `checks run` feature in github is a good solution for this issue, looks it's Upgraded `commit status`. the difference betwen `check run` and `commit status` : ![image](https://user-images.githubusercontent.com/25342410/229058400-124620cc-e4f9-41f4-9496-7a335c23d435.png) in my view, looks `check run` = `commit status` + `code review` some tips about do it: - github api document: https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28 - wonder whether create a new table named as `CheckRun` or just upgrade the `CommitStatus` struct - in github's document description, it bound with `App` feature, but in fact, looks it bound with `Action` also ... ![image](https://user-images.githubusercontent.com/25342410/229070987-78d8bacc-16ae-4316-bc94-f9489c49687a.png) --- ![屏幕截图 2023-03-31 163821](https://user-images.githubusercontent.com/25342410/229070727-476130db-324e-4cd2-b1b0-78efd7cc091f.png) - To show it on ui, maybe we can reuse `commit status` and `code comment` ui - `checkRun` db struct in my view: ```Go type ChekRun struct { ID int64 `xorm:"pk autoincr"` RepoID int64 `xorm:"INDEX UNIQUE(repo_sha_index)"` Repo *repo_model.Repository `xorm:"-"` State int64 // difference with `CommitStatus` Conclusion int64 // difference with `CommitStatus` SHA string `xorm:"VARCHAR(64) NOT NULL INDEX UNIQUE(repo_sha_index)"` TargetURL string `xorm:"TEXT"` NameHash string `xorm:"char(40) index"` Name string `xorm:"TEXT"` Creator *user_model.User `xorm:"-"` CreatorID int64 StartAt timeutil.TimeStamp // difference with `CommitStatus` CompletedAt timeutil.TimeStamp // difference with `CommitStatus` OutPut *ChekRunOutPut `xorm:"-"` // difference with `CommitStatus` Actions []ChekRunAction `xorm:"-"` // difference with `CommitStatus` CreatedUnix timeutil.TimeStamp `xorm:"INDEX created"` UpdatedUnix timeutil.TimeStamp `xorm:"INDEX updated"` } type ChekRunAnnotation struct { Path string StartLine int64 EndLine int64 StartColumn int64 EndColumn int64 AnnotationLevel string Message string Title string RawDetails string } type ChekRunOutPut struct { ID int64 `xorm:"pk autoincr"` ChekcRunID int64 `xorm:"INDEX"` Title string Summary string Text string Annotations []ChekRunAnnotation `xorm:"JSON"` } type ChekRunAction struct { ID int64 `xorm:"pk autoincr"` ChekcRunID int64 `xorm:"INDEX"` Label string Description string Identifier string Url string } ```

GiteaMirror commented

2025-11-02 09:10:56 -06:00

@wxiaoguang commented on GitHub (Apr 23, 2025):

The "AP endpoint session access" has been completely dropped long time ago. So I guess it's impossible to have such API anymore.

@wxiaoguang commented on GitHub (Apr 23, 2025): The "AP endpoint session access" has been completely dropped long time ago. So I guess it's impossible to have such API anymore.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10546