gitea

Commit Graph

Author	SHA1	Message	Date
wxiaoguang	236c645bf1	Refactor "Content" for file uploading (#25851 ) Before: the concept "Content string" is used everywhere. It has some problems: 1. Sometimes it means "base64 encoded content", sometimes it means "raw binary content" 2. It doesn't work with large files, eg: uploading a 1G LFS file would make Gitea process OOM This PR does the refactoring: use "ContentReader" / "ContentBase64" instead of "Content" This PR is not breaking because the key in API JSON is still "content": `` ContentBase64 string `json:"content"` ``	2 years ago
Zettat123	a42a838843	Fix `ref` for workflows triggered by `pull_request_target` (#25743 ) Follow #25229 At present, when the trigger event is `pull_request_target`, the `ref` and `sha` of `ActionRun` are set according to the base branch of the pull request. This makes it impossible for us to find the head branch of the `ActionRun` directly. In this PR, the `ref` and `sha` will always be set to the head branch and they will be changed to the base branch when generating the task context.	2 years ago
Zettat123	48e5a74f21	Support `pull_request_target` event (#25229 ) Fix #25088 This PR adds the support for [`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) workflow trigger. `pull_request_target` is similar to `pull_request`, but the workflow triggered by the `pull_request_target` event runs in the context of the base branch of the pull request rather than the head branch. Since the workflow from the base is considered trusted, it can access the secrets and doesn't need approvals to run.	2 years ago

Author

SHA1

Message

Date

wxiaoguang

236c645bf1

Refactor "Content" for file uploading (#25851 )

Before: the concept "Content string" is used everywhere. It has some
problems:

1. Sometimes it means "base64 encoded content", sometimes it means "raw
binary content"
2. It doesn't work with large files, eg: uploading a 1G LFS file would
make Gitea process OOM

This PR does the refactoring: use "ContentReader" / "ContentBase64"
instead of "Content"

This PR is not breaking because the key in API JSON is still "content":
`` ContentBase64 string `json:"content"` ``

2 years ago

Zettat123

a42a838843

Fix `ref` for workflows triggered by `pull_request_target` (#25743 )

Follow #25229

At present, when the trigger event is `pull_request_target`, the `ref`
and `sha` of `ActionRun` are set according to the base branch of the
pull request. This makes it impossible for us to find the head branch of
the `ActionRun` directly. In this PR, the `ref` and `sha` will always be
set to the head branch and they will be changed to the base branch when
generating the task context.

2 years ago

Zettat123

48e5a74f21

Support `pull_request_target` event (#25229 )

Fix #25088

This PR adds the support for
[`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)
workflow trigger. `pull_request_target` is similar to `pull_request`,
but the workflow triggered by the `pull_request_target` event runs in
the context of the base branch of the pull request rather than the head
branch. Since the workflow from the base is considered trusted, it can
access the secrets and doesn't need approvals to run.

2 years ago

3 Commits (1c89f15f42411e2271d809e0d4c311cc145a4d75)