3 Commits

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"` ``	2023-07-18 18:14:47 +00:00
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.	2023-07-07 19:22:03 +00:00
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.	2023-06-26 14:33:18 +08:00