mirror of https://github.com/go-gitea/gitea
Tag:
Branch:
Tree:
b46c46f3a3
main
release/v1.10
release/v1.11
release/v1.12
release/v1.13
release/v1.14
release/v1.15
release/v1.16
release/v1.17
release/v1.18
release/v1.19
release/v1.20
release/v1.21
release/v1.22
release/v1.22-legacy
release/v1.8
release/v1.9
v0.9.99
v1.0.0
v1.0.1
v1.0.2
v1.1.0
v1.1.1
v1.1.2
v1.1.3
v1.1.4
v1.10.0
v1.10.0-dev
v1.10.0-rc1
v1.10.0-rc2
v1.10.1
v1.10.2
v1.10.3
v1.10.4
v1.10.5
v1.10.6
v1.11.0
v1.11.0-dev
v1.11.0-rc1
v1.11.0-rc2
v1.11.1
v1.11.2
v1.11.3
v1.11.4
v1.11.5
v1.11.6
v1.11.7
v1.11.8
v1.12.0
v1.12.0-dev
v1.12.0-rc1
v1.12.0-rc2
v1.12.1
v1.12.2
v1.12.3
v1.12.4
v1.12.5
v1.12.6
v1.13.0
v1.13.0-dev
v1.13.0-rc1
v1.13.0-rc2
v1.13.1
v1.13.2
v1.13.3
v1.13.4
v1.13.5
v1.13.6
v1.13.7
v1.14.0
v1.14.0-dev
v1.14.0-rc1
v1.14.0-rc2
v1.14.1
v1.14.2
v1.14.3
v1.14.4
v1.14.5
v1.14.6
v1.14.7
v1.15.0
v1.15.0-dev
v1.15.0-rc1
v1.15.0-rc2
v1.15.0-rc3
v1.15.1
v1.15.10
v1.15.11
v1.15.2
v1.15.3
v1.15.4
v1.15.5
v1.15.6
v1.15.7
v1.15.8
v1.15.9
v1.16.0
v1.16.0-dev
v1.16.0-rc1
v1.16.1
v1.16.2
v1.16.3
v1.16.4
v1.16.5
v1.16.6
v1.16.7
v1.16.8
v1.16.9
v1.17.0
v1.17.0-dev
v1.17.0-rc1
v1.17.0-rc2
v1.17.1
v1.17.2
v1.17.3
v1.17.4
v1.18.0
v1.18.0-dev
v1.18.0-rc0
v1.18.0-rc1
v1.18.1
v1.18.2
v1.18.3
v1.18.4
v1.18.5
v1.19.0
v1.19.0-dev
v1.19.0-rc0
v1.19.0-rc1
v1.19.1
v1.19.2
v1.19.3
v1.19.4
v1.2.0
v1.2.0-rc1
v1.2.0-rc2
v1.2.0-rc3
v1.2.1
v1.2.2
v1.2.3
v1.20.0
v1.20.0-dev
v1.20.0-rc0
v1.20.0-rc1
v1.20.0-rc2
v1.20.1
v1.20.2
v1.20.3
v1.20.4
v1.20.5
v1.20.6
v1.21.0
v1.21.0-dev
v1.21.0-rc0
v1.21.0-rc1
v1.21.0-rc2
v1.21.1
v1.21.10
v1.21.11
v1.21.2
v1.21.3
v1.21.4
v1.21.5
v1.21.6
v1.21.7
v1.21.8
v1.21.9
v1.22.0
v1.22.0-dev
v1.22.0-rc0
v1.22.0-rc1
v1.22.1
v1.22.2
v1.22.3
v1.23.0-dev
v1.3.0
v1.3.0-rc1
v1.3.0-rc2
v1.3.1
v1.3.2
v1.3.3
v1.4.0
v1.4.0-rc1
v1.4.0-rc2
v1.4.0-rc3
v1.4.1
v1.4.2
v1.4.3
v1.5.0
v1.5.0-dev
v1.5.0-rc1
v1.5.0-rc2
v1.5.1
v1.5.2
v1.5.3
v1.6.0
v1.6.0-dev
v1.6.0-rc1
v1.6.0-rc2
v1.6.1
v1.6.2
v1.6.3
v1.6.4
v1.7.0
v1.7.0-dev
v1.7.0-rc1
v1.7.0-rc2
v1.7.0-rc3
v1.7.1
v1.7.2
v1.7.3
v1.7.4
v1.7.5
v1.7.6
v1.8.0
v1.8.0-rc1
v1.8.0-rc2
v1.8.0-rc3
v1.8.1
v1.8.2
v1.8.3
v1.9.0
v1.9.0-dev
v1.9.0-rc1
v1.9.0-rc2
v1.9.1
v1.9.2
v1.9.3
v1.9.4
v1.9.5
v1.9.6
${ noResults }
10 Commits (b46c46f3a3a0c09ade5a57e1693e2e6a5d07c120)
Author | SHA1 | Message | Date |
---|---|---|---|
sillyguodong |
023e61e678
|
Create commit status when event is `pull_request_sync` (#23683)
Fix: #23674 If the type of `hook_event` is `pull_request_sync`, also need to insert a record of `commit_status` into DB. Because `pull_request` event and `pull_request_sync` event have the same payload, so the code is reusable. Screenshot: ![image](https://user-images.githubusercontent.com/33891828/227465436-1b436807-d0b2-4a2b-8890-09d96c7f666d.png) |
2 years ago |
Zettat123 |
9e04627aca
|
Fix incorrect `HookEventType` of pull request review comments (#23650)
`HookEventType` of pull request review comments should be `HookEventPullRequestReviewComment` but some event types are `HookEventPullRequestComment` now. |
2 years ago |
sillyguodong |
5eea61dbc8
|
Fix missing commit status in PR which from forked repo (#23351)
close: #23347
### Reference and Inference
According to Github REST API
[doc](https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#list-commit-statuses-for-a-reference):
1. The `Drone CI` that can create some commit status by
[API](https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#create-a-commit-status)
is enabled in `go-gitea/gitea`. So I tried to call the API to get a
commit status list of a PR which is commited to upstream
repo(`go-gitea/gitea`). As a result, the API returned a array of commit
status.
![image](https://user-images.githubusercontent.com/33891828/223913371-313d047a-5e2e-484c-b13e-dcd38748703e.png)
2. Then I tried to call the API to get commit status list of the
reference which of the `SHA` is the same as step 1 in the repo which is
forked from `go-gitea/gitea`. But I got a empty array.
![image](https://user-images.githubusercontent.com/33891828/223930827-17a64d3c-f466-4980-897c-77fe386c4d3b.png)
So, I believe it that:
1. The commit status is not shared between upstream repo and forked
repo.
2. The coomit status is bound to a repo that performs actions. (Gitea's
logic is the same)
### Cause
During debugging, I found it that commit status are not stored in the DB
as expected.
So, I located the following code:
|
2 years ago |
Jason Song |
47b912cd52
|
Avoid panic caused by broken payload when creating commit status (#23216)
When creating commit status for Actons jobs, a payload with nil `HeadCommit` will cause panic. Reported at: https://gitea.com/gitea/act_runner/issues/28#issuecomment-732166 Although the `HeadCommit` probably can not be nil after #23215, `CreateCommitStatus` should protect itself, to avoid being broken in the future. In addition, it's enough to print error log instead of returning err when `CreateCommitStatus` failed. --------- Co-authored-by: delvh <dev.lh@web.de> |
2 years ago |
Jason Song |
edf98a2dc3
|
Require approval to run actions for fork pull request (#22803)
Currently, Gitea will run actions automatically which are triggered by fork pull request. It's a security risk, people can create a PR and modify the workflow yamls to execute a malicious script. So we should require approval for first-time contributors, which is the default strategy of a public repo on GitHub, see [Approving workflow runs from public forks](https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks). Current strategy: - don't need approval if it's not a fork PR; - always need approval if the user is restricted; - don't need approval if the user can write; - don't need approval if the user has been approved before; - otherwise, need approval. https://user-images.githubusercontent.com/9418365/217207121-badf50a8-826c-4425-bef1-d82d1979bc81.mov GitHub has an option for that, you can see that at `/<owner>/<repo>/settings/actions`, and we can support that later. <img width="835" alt="image" src="https://user-images.githubusercontent.com/9418365/217199990-2967e68b-e693-4e59-8186-ab33a1314a16.png"> --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> |
2 years ago |
Lunny Xiao |
bd820aa9c5
|
Add context cache as a request level cache (#22294)
To avoid duplicated load of the same data in an HTTP request, we can set a context cache to do that. i.e. Some pages may load a user from a database with the same id in different areas on the same page. But the code is hidden in two different deep logic. How should we share the user? As a result of this PR, now if both entry functions accept `context.Context` as the first parameter and we just need to refactor `GetUserByID` to reuse the user from the context cache. Then it will not be loaded twice on an HTTP request. But of course, sometimes we would like to reload an object from the database, that's why `RemoveContextData` is also exposed. The core context cache is here. It defines a new context ```go type cacheContext struct { ctx context.Context data map[any]map[any]any lock sync.RWMutex } var cacheContextKey = struct{}{} func WithCacheContext(ctx context.Context) context.Context { return context.WithValue(ctx, cacheContextKey, &cacheContext{ ctx: ctx, data: make(map[any]map[any]any), }) } ``` Then you can use the below 4 methods to read/write/del the data within the same context. ```go func GetContextData(ctx context.Context, tp, key any) any func SetContextData(ctx context.Context, tp, key, value any) func RemoveContextData(ctx context.Context, tp, key any) func GetWithContextCache[T any](ctx context.Context, cacheGroupKey string, cacheTargetID any, f func() (T, error)) (T, error) ``` Then let's take a look at how `system.GetString` implement it. ```go func GetSetting(ctx context.Context, key string) (string, error) { return cache.GetWithContextCache(ctx, contextCacheKey, key, func() (string, error) { return cache.GetString(genSettingCacheKey(key), func() (string, error) { res, err := GetSettingNoCache(ctx, key) if err != nil { return "", err } return res.SettingValue, nil }) }) } ``` First, it will check if context data include the setting object with the key. If not, it will query from the global cache which may be memory or a Redis cache. If not, it will get the object from the database. In the end, if the object gets from the global cache or database, it will be set into the context cache. An object stored in the context cache will only be destroyed after the context disappeared. |
2 years ago |
wxiaoguang |
e9288c2477
|
Fix improper HTMLURL usages in Go code (#22839)
In Go code, HTMLURL should be only used for external systems, like API/webhook/mail/notification, etc. If a URL is used by `Redirect` or rendered in a template, it should be a relative URL (aka `Link()` in Gitea) Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> |
2 years ago |
Lunny Xiao |
2871ea0809
|
Add more events details supports for actions (#22680)
#21937 implemented only basic events based on name because of `act`'s limitation. So I sent a PR to parse all possible events details in https://gitea.com/gitea/act/pulls/11 and it merged. The ref documentation is https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows This PR depends on that and make more detail responses for `push` events and `pull_request` events. And it lefts more events there for future PRs. --------- Co-authored-by: Jason Song <i@wolfogre.com> |
2 years ago |
Jason Song |
707ecec715
|
Fix ref to trigger Actions (#22679)
If triggered by PR, the ref should be `pull/<index>/head` instead of `repo.DefaultBranch`. And improve UI: <img width="493" alt="image" src="https://user-images.githubusercontent.com/9418365/215731280-312564f2-2450-45d0-b986-1accb0670976.png"> Related to #21937. |
2 years ago |
Jason Song |
4011821c94
|
Implement actions (#21937)
Close #13539. Co-authored by: @lunny @appleboy @fuxiaohei and others. Related projects: - https://gitea.com/gitea/actions-proto-def - https://gitea.com/gitea/actions-proto-go - https://gitea.com/gitea/act - https://gitea.com/gitea/act_runner ### Summary The target of this PR is to bring a basic implementation of "Actions", an internal CI/CD system of Gitea. That means even though it has been merged, the state of the feature is **EXPERIMENTAL**, and please note that: - It is disabled by default; - It shouldn't be used in a production environment currently; - It shouldn't be used in a public Gitea instance currently; - Breaking changes may be made before it's stable. **Please comment on #13539 if you have any different product design ideas**, all decisions reached there will be adopted here. But in this PR, we don't talk about **naming, feature-creep or alternatives**. ### ⚠️ Breaking `gitea-actions` will become a reserved user name. If a user with the name already exists in the database, it is recommended to rename it. ### Some important reviews - What is `DEFAULT_ACTIONS_URL` in `app.ini` for? - https://github.com/go-gitea/gitea/pull/21937#discussion_r1055954954 - Why the api for runners is not under the normal `/api/v1` prefix? - https://github.com/go-gitea/gitea/pull/21937#discussion_r1061173592 - Why DBFS? - https://github.com/go-gitea/gitea/pull/21937#discussion_r1061301178 - Why ignore events triggered by `gitea-actions` bot? - https://github.com/go-gitea/gitea/pull/21937#discussion_r1063254103 - Why there's no permission control for actions? - https://github.com/go-gitea/gitea/pull/21937#discussion_r1090229868 ### What it looks like <details> #### Manage runners <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205870657-c72f590e-2e08-4cd4-be7f-2e0abb299bbf.png"> #### List runs <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205872794-50fde990-2b45-48c1-a178-908e4ec5b627.png"> #### View logs <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205872501-9b7b9000-9542-4991-8f55-18ccdada77c3.png"> </details> ### How to try it <details> #### 1. Start Gitea Clone this branch and [install from source](https://docs.gitea.io/en-us/install-from-source). Add additional configurations in `app.ini` to enable Actions: ```ini [actions] ENABLED = true ``` Start it. If all is well, you'll see the management page of runners: <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205877365-8e30a780-9b10-4154-b3e8-ee6c3cb35a59.png"> #### 2. Start runner Clone the [act_runner](https://gitea.com/gitea/act_runner), and follow the [README](https://gitea.com/gitea/act_runner/src/branch/main/README.md) to start it. If all is well, you'll see a new runner has been added: <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205878000-216f5937-e696-470d-b66c-8473987d91c3.png"> #### 3. Enable actions for a repo Create a new repo or open an existing one, check the `Actions` checkbox in settings and submit. <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205879705-53e09208-73c0-4b3e-a123-2dcf9aba4b9c.png"> <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205879383-23f3d08f-1a85-41dd-a8b3-54e2ee6453e8.png"> If all is well, you'll see a new tab "Actions": <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205881648-a8072d8c-5803-4d76-b8a8-9b2fb49516c1.png"> #### 4. Upload workflow files Upload some workflow files to `.gitea/workflows/xxx.yaml`, you can follow the [quickstart](https://docs.github.com/en/actions/quickstart) of GitHub Actions. Yes, Gitea Actions is compatible with GitHub Actions in most cases, you can use the same demo: ```yaml name: GitHub Actions Demo run-name: ${{ github.actor }} is testing out GitHub Actions 🚀 on: [push] jobs: Explore-GitHub-Actions: runs-on: ubuntu-latest steps: - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!" - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}." - name: Check out repository code uses: actions/checkout@v3 - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner." - run: echo "🖥️ The workflow is now ready to test your code on the runner." - name: List files in the repository run: | ls ${{ github.workspace }} - run: echo "🍏 This job's status is ${{ job.status }}." ``` If all is well, you'll see a new run in `Actions` tab: <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205884473-79a874bc-171b-4aaf-acd5-0241a45c3b53.png"> #### 5. Check the logs of jobs Click a run and you'll see the logs: <img width="1792" alt="image" src="https://user-images.githubusercontent.com/9418365/205884800-994b0374-67f7-48ff-be9a-4c53f3141547.png"> #### 6. Go on You can try more examples in [the documents](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) of GitHub Actions, then you might find a lot of bugs. Come on, PRs are welcome. </details> See also: [Feature Preview: Gitea Actions](https://blog.gitea.io/2022/12/feature-preview-gitea-actions/) --------- Co-authored-by: a1012112796 <1012112796@qq.com> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: delvh <dev.lh@web.de> Co-authored-by: ChristopherHX <christopher.homberger@web.de> Co-authored-by: John Olheiser <john.olheiser@gmail.com> |
2 years ago |