summaryrefslogtreecommitdiffstats
path: root/services/webhook
Commit message (Collapse)AuthorAgeFilesLines
* Enable tenv and testifylint rules (#32852)TheFox0x72024-12-152-17/+17
| | | | Enables tenv and testifylint linters closes: https://github.com/go-gitea/gitea/issues/32842
* Only provide the commit summary for Discord webhook push events (#32432)Kemal Zebari2024-11-073-3/+17
| | | | | | | | | | | | Resolves #32371. #31970 should have just showed the commit summary, but `strings.SplitN()` was misused such that we did not perform any splitting at all and just used the message. This was not caught in the unit test made in that PR since the test commit summary was > 50 (which truncated away the commit description). This snapshot resolves this and adds another unit test to ensure that we only show the commit summary.
* Add new event commit status creation and webhook implementation (#27151)Lunny Xiao2024-11-071-0/+31
| | | | | | | | | | | This PR introduces a new event which is similar as Github's. When a new commit status submitted, the event will be trigged. That means, now we can receive all feedback from CI/CD system in webhooks or other notify systems. ref: https://docs.github.com/en/webhooks/webhook-events-and-payloads#status Fix #20749
* Support requested_reviewers data in comment webhook events (#26178)谈笑风生间2024-10-161-32/+42
| | | | | | | | | | | close #25833 Currently, the information for "requested_reviewers" is only included in the webhook event for reviews. I would like to suggest adding this information to the webhook event for "PullRequest comment" as well, as they both pertain to the "PullRequest" event. Also, The reviewer information for the Pull Request is not displayed when it is approved or rejected.
* Truncate commit message during Discord webhook push events (#31970)Kemal Zebari2024-09-243-3/+32
| | | Resolves #31668.
* Support allowed hosts for migrations to work with proxy (#32025)Jason Song2024-09-111-1/+1
|
* Refactor webhook (#31587)wxiaoguang2024-07-1014-177/+161
| | | | | | A more complete fix for #31588 1. Make "generic" code more readable 2. Clarify HTML or Markdown for the payload content
* Enable `unparam` linter (#31277)silverwind2024-06-119-9/+9
| | | | | | | | | | | | Enable [unparam](https://github.com/mvdan/unparam) linter. Often I could not tell the intention why param is unused, so I put `//nolint` for those cases like webhook request creation functions never using `ctx`. --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: delvh <dev.lh@web.de>
* Enable more `revive` linter rules (#30608)silverwind2024-04-222-3/+0
| | | | | | | | | | | Noteable additions: - `redefines-builtin-id` forbid variable names that shadow go builtins - `empty-lines` remove unnecessary empty lines that `gofumpt` does not remove for some reason - `superfluous-else` eliminate more superfluous `else` branches Rules are also sorted alphabetically and I cleaned up various parts of `.golangci.yml`.
* Fix missed doer (#30231)Lunny Xiao2024-04-081-11/+11
| | | | | Fix #29879 Co-authored-by: Giteabot <teabot@gitea.io>
* Fix possible data race on tests (#30093)Lunny Xiao2024-03-261-1/+0
|
* Upgrade Go 1.22 and upgrade dependency (#29869)wxiaoguang2024-03-171-1/+0
|
* fix telegram webhook (#29864)Denys Konovalov2024-03-172-1/+12
| | | | | | | | | | | Fix #29837 which is a regression caused by https://github.com/go-gitea/gitea/pull/29145/files#diff-731445ee00f0f1bf2ff731f4f96ddcf51cdc53fd2faaf406eb3536fc292ea748L48. The line was probably removed by accident. --------- Co-authored-by: Giteabot <teabot@gitea.io>
* Add test for webhook (#29755)wxiaoguang2024-03-141-49/+29
| | | Follow #29690
* Fix broken webhooks (#29690)Lunny Xiao2024-03-101-1/+6
| | | Fix #29689
* Store webhook event in database (#29145)oliverpool2024-03-0722-1503/+1613
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the webhook logic, to have the type-dependent processing happen only in one place. --- ## Current webhook flow 1. An event happens 2. It is pre-processed (depending on the webhook type) and its body is added to a task queue 3. When the task is processed, some more logic (depending on the webhook type as well) is applied to make an HTTP request This means that webhook-type dependant logic is needed in step 2 and 3. This is cumbersome and brittle to maintain. Updated webhook flow with this PR: 1. An event happens 2. It is stored as-is and added to a task queue 3. When the task is processed, the event is processed (depending on the webhook type) to make an HTTP request So the only webhook-type dependent logic happens in one place (step 3) which should be much more robust. ## Consequences of the refactor - the raw event must be stored in the hooktask (until now, the pre-processed body was stored) - to ensure that previous hooktasks are correctly sent, a `payload_version` is added (version 1: the body has already been pre-process / version 2: the body is the raw event) So future webhook additions will only have to deal with creating an http.Request based on the raw event (no need to adjust the code in multiple places, like currently). Moreover since this processing happens when fetching from the task queue, it ensures that the queuing of new events (upon a `git push` for instance) does not get slowed down by a slow webhook. As a concrete example, the PR #19307 for custom webhooks, should be substantially smaller: - no need to change `services/webhook/deliver.go` - minimal change in `services/webhook/webhook.go` (add the new webhook to the map) - no need to change all the individual webhook files (since with this refactor the `*webhook_model.Webhook` is provided as argument)
* remove util.OptionalBool and related functions (#29513)65432024-03-021-3/+4
| | | | | | and migrate affected code _last refactoring bits to replace **util.OptionalBool** with **optional.Option[bool]**_
* Use `crypto/sha256` (#29386)KN4CK3R2024-02-251-1/+1
| | | | | | | | Go 1.21 improved the performance of `crypto/sha256`. It's now similar to `minio/sha256-simd`, so we should just use the standard libs. https://go.dev/doc/go1.21#crypto/sha256 https://go-review.googlesource.com/c/go/+/408795 https://github.com/multiformats/go-multihash/pull/173
* Abstract hash function usage (#28138)Adam Majer2023-12-131-0/+1
| | | | | | Refactor Hash interfaces and centralize hash function. This will allow easier introduction of different hash function later on. This forms the "no-op" part of the SHA256 enablement patch.
* Use db.Find instead of writing methods for every object (#28084)Lunny Xiao2023-11-241-2/+3
| | | | For those simple objects, it's unnecessary to write the find and count methods again and again.
* Fix Matrix and MSTeams nil dereference (#28089)KN4CK3R2023-11-1711-6/+155
| | | | | | | | | | Fixes #28088 Fixes #28094 Added missing tests. --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Fix package webhook (#27839)Lunny Xiao2023-10-3111-1/+91
| | | | | | | Fix #23742 --------- Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
* Support allowed hosts for webhook to work with proxy (#27655)Jason Song2023-10-182-18/+58
| | | | | | | | | | | | | | | | | When `webhook.PROXY_URL` has been set, the old code will check if the proxy host is in `ALLOWED_HOST_LIST` or reject requests through the proxy. It requires users to add the proxy host to `ALLOWED_HOST_LIST`. However, it actually allows all requests to any port on the host, when the proxy host is probably an internal address. But things may be even worse. `ALLOWED_HOST_LIST` doesn't really work when requests are sent to the allowed proxy, and the proxy could forward them to any hosts. This PR fixes it by: - If the proxy has been set, always allow connectioins to the host and port. - Check `ALLOWED_HOST_LIST` before forwarding.
* Final round of `db.DefaultContext` refactor (#27587)JakobDev2023-10-141-3/+3
| | | Last part of #27065
* make writing main test easier (#27270)Lunny Xiao2023-09-281-2/+0
| | | | | | | | | This PR removed `unittest.MainTest` the second parameter `TestOptions.GiteaRoot`. Now it detects the root directory by current working directory. --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Fix release URL in webhooks (#27182)John Olheiser2023-09-219-9/+9
|
* move repository deletion to service layer (#26948)Lunny Xiao2023-09-081-0/+1
| | | Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Move notification interface to services layer (#26915)Lunny Xiao2023-09-051-47/+46
| | | Extract from #22266
* Modify the content format of the Feishu webhook (#25106)谈笑风生间2023-08-244-15/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | close https://github.com/go-gitea/gitea/issues/24368 ## what my pull request does Since the official documentation states that custom bots do not support hyperlink functionality, simply adding it without making some formatting changes would result in an unappealing output. Therefore, I have modified the formatting of the output. Currently, it is only used for Feishu. --- [docs](https://open.feishu.cn/document/uAjLw4CM/ukTMukTMukTM/im-v1/message/create_json#%E8%B6%85%E9%93%BE%E6%8E%A5%E4%BD%BF%E7%94%A8%E8%AF%B4%E6%98%8E) <img width="641" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/360e1c81-ab64-4ef6-851e-aa450d6e85a4"> - Issue <img width="423" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/519f6fae-81ab-4ec8-89b8-f6a73ff93783"> - Issue Comment <img width="548" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/749c0d1c-3657-431e-b787-8bf4c23cce83"> - Assign <img width="431" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/066f99e5-eabb-455d-91fb-a8359cc26dc7"> <img width="457" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/c6c10f99-db83-46ef-a775-4c91979fa68f"> - Merge <img width="408" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/e627bf43-5954-45aa-acf6-261ee046802f"> - PullRequest <img width="425" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/72cfa714-d3fa-4fb9-abdd-e8508d756056">
* Add `branch_filter` to hooks API endpoints (#26599)Yarden Shoham2023-08-211-0/+1
| | | | | | | | | | | | | | | | | | We now include the branch filler in the response. - Closes #26591 # Before ![image](https://github.com/go-gitea/gitea/assets/20454870/73933940-c1a7-4573-abae-f340b63028b2) # After ![image](https://github.com/go-gitea/gitea/assets/20454870/3b3c4a85-0f7c-48c7-8617-def7a66c671d) --------- Signed-off-by: Yarden Shoham <git@yardenshoham.com> Co-authored-by: Giteabot <teabot@gitea.io>
* Add ThreadID parameter for Telegram webhooks (#25996)Earl Warren2023-08-131-0/+1
| | | | | | Telegram has recently implemented threads (channels) for group chats. Co-authored-by: neveraskedtoexist <matikot415@gmail.com>
* Add pull request review request webhook event (#26401)Yarden Shoham2023-08-091-0/+4
| | | | | | | | | | | | | | | | | | | | Add webhook events for pull request review requests - Fixes #26371 - Added support for the "Pull request review requested" and "Pull request review request removed" webhook events. - Updated the `getPullRequestPayloadInfo` function in `general.go` to handle these new webhook events. # Before ![image](https://github.com/go-gitea/gitea/assets/20454870/bd942971-fb1d-40f3-8961-46638e3588fa) # After ![image](https://github.com/go-gitea/gitea/assets/20454870/216e9c7d-0a4d-49f9-8492-2d14c88bbf4e) Signed-off-by: Yarden Shoham <git@yardenshoham.com> Co-authored-by: Giteabot <teabot@gitea.io>
* Warn instead of reporting an error when a webhook cannot be found (#26039)puni98692023-07-281-1/+6
| | | | | | | | | Attemp fix: #25744 Fixing the log level when we delete any repo then we get error hook not found by id. That should be warn level to reduce the noise in the logs. --------- Co-authored-by: delvh <dev.lh@web.de>
* For API attachments, use API URL (#25639)Lunny Xiao2023-07-101-4/+4
| | | | | | | Fix #25257 --------- Co-authored-by: Giteabot <teabot@gitea.io>
* Fix `Permission` in API returned repository struct (#25388)Jason Song2023-06-221-60/+59
| | | | | | | | | | | | | | | | | | | | | | | The old code generates `structs.Repository.Permissions` with only `access.Permission.AccessMode`, however, it should check the units too, or the value could be incorrect. For example, `structs.Repository.Permissions.Push` could be false even the doer has write access to code unit. Should fix https://github.com/renovatebot/renovate/issues/14059#issuecomment-1047961128 (Not reported by it, I just found it when I was looking into this bug) --- Review tips: The major changes are - `modules/structs/repo.go` https://github.com/go-gitea/gitea/pull/25388/files#diff-870406f6857117f8b03611c43fca0ab9ed6d6e76a2d0069a7c1f17e8fa9092f7 - `services/convert/repository.go` https://github.com/go-gitea/gitea/pull/25388/files#diff-7736f6d2ae894c9edb7729a80ab89aa183b888a26a811a0c1fdebd18726a7101 And other changes are passive.
* Fix compatible for webhook ref type (#25195)Lunny Xiao2023-06-131-3/+3
| | | | Fix #25185 Caused by #24634
* Rename NotifyPullReviewRequest to NotifyPullRequestReviewRequest (#24988)谈笑风生间2023-05-311-2/+2
| | | | | | | | | | | | after #24481 To keep consistent, maybe pull_request_review_request is better. ## what my pull request does Rename NotifyPullReviewRequest to NotifyPullRequestReviewRequest. <img width="1087" alt="image" src="https://github.com/go-gitea/gitea/assets/75628309/2cf91f02-74f2-42fe-a998-0a039b821d8d">
* Improve queue and logger context (#24924)wxiaoguang2023-05-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Before there was a "graceful function": RunWithShutdownFns, it's mainly for some modules which doesn't support context. The old queue system doesn't work well with context, so the old queues need it. After the queue refactoring, the new queue works with context well, so, use Golang context as much as possible, the `RunWithShutdownFns` could be removed (replaced by RunWithCancel for context cancel mechanism), the related code could be simplified. This PR also fixes some legacy queue-init problems, eg: * typo : archiver: "unable to create codes indexer queue" => "unable to create repo-archive queue" * no nil check for failed queues, which causes unfriendly panic After this PR, many goroutines could have better display name: ![image](https://github.com/go-gitea/gitea/assets/2114189/701b2a9b-8065-4137-aeaa-0bda2b34604a) ![image](https://github.com/go-gitea/gitea/assets/2114189/f1d5f50f-0534-40f0-b0be-f2c9daa5fe92)
* Use the type RefName for all the needed places and fix pull mirror sync bugs ↵Lunny Xiao2023-05-269-37/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#24634) This PR replaces all string refName as a type `git.RefName` to make the code more maintainable. Fix #15367 Replaces #23070 It also fixed a bug that tags are not sync because `git remote --prune origin` will not remove local tags if remote removed. We in fact should use `git fetch --prune --tags origin` but not `git remote update origin` to do the sync. Some answer from ChatGPT as ref. > If the git fetch --prune --tags command is not working as expected, there could be a few reasons why. Here are a few things to check: > >Make sure that you have the latest version of Git installed on your system. You can check the version by running git --version in your terminal. If you have an outdated version, try updating Git and see if that resolves the issue. > >Check that your Git repository is properly configured to track the remote repository's tags. You can check this by running git config --get-all remote.origin.fetch and verifying that it includes +refs/tags/*:refs/tags/*. If it does not, you can add it by running git config --add remote.origin.fetch "+refs/tags/*:refs/tags/*". > >Verify that the tags you are trying to prune actually exist on the remote repository. You can do this by running git ls-remote --tags origin to list all the tags on the remote repository. > >Check if any local tags have been created that match the names of tags on the remote repository. If so, these local tags may be preventing the git fetch --prune --tags command from working properly. You can delete local tags using the git tag -d command. --------- Co-authored-by: delvh <dev.lh@web.de>
* New webhook trigger for receiving Pull Request review requests (#24481)谈笑风生间2023-05-242-1/+29
| | | | | | | | | | | | | | | | | | | close https://github.com/go-gitea/gitea/issues/16321 Provided a webhook trigger for requesting someone to review the Pull Request. Some modifications have been made to the returned `PullRequestPayload` based on the GitHub webhook settings, including: - add a description of the current reviewer object as `RequestedReviewer` . - setting the action to either **review_requested** or **review_request_removed** based on the operation. - adding the `RequestedReviewers` field to the issues_model.PullRequest. This field will be loaded into the PullRequest through `LoadRequestedReviewers()` when `ToAPIPullRequest` is called. After the Pull Request is merged, I will supplement the relevant documentation.
* Rewrite queue (#24505)wxiaoguang2023-05-082-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | # ⚠️ Breaking Many deprecated queue config options are removed (actually, they should have been removed in 1.18/1.19). If you see the fatal message when starting Gitea: "Please update your app.ini to remove deprecated config options", please follow the error messages to remove these options from your app.ini. Example: ``` 2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]` 2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]` 2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options ``` Many options in `[queue]` are are dropped, including: `WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`, `BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed from app.ini. # The problem The old queue package has some legacy problems: * complexity: I doubt few people could tell how it works. * maintainability: Too many channels and mutex/cond are mixed together, too many different structs/interfaces depends each other. * stability: due to the complexity & maintainability, sometimes there are strange bugs and difficult to debug, and some code doesn't have test (indeed some code is difficult to test because a lot of things are mixed together). * general applicability: although it is called "queue", its behavior is not a well-known queue. * scalability: it doesn't seem easy to make it work with a cluster without breaking its behaviors. It came from some very old code to "avoid breaking", however, its technical debt is too heavy now. It's a good time to introduce a better "queue" package. # The new queue package It keeps using old config and concept as much as possible. * It only contains two major kinds of concepts: * The "base queue": channel, levelqueue, redis * They have the same abstraction, the same interface, and they are tested by the same testing code. * The "WokerPoolQueue", it uses the "base queue" to provide "worker pool" function, calls the "handler" to process the data in the base queue. * The new code doesn't do "PushBack" * Think about a queue with many workers, the "PushBack" can't guarantee the order for re-queued unhandled items, so in new code it just does "normal push" * The new code doesn't do "pause/resume" * The "pause/resume" was designed to handle some handler's failure: eg: document indexer (elasticsearch) is down * If a queue is paused for long time, either the producers blocks or the new items are dropped. * The new code doesn't do such "pause/resume" trick, it's not a common queue's behavior and it doesn't help much. * If there are unhandled items, the "push" function just blocks for a few seconds and then re-queue them and retry. * The new code doesn't do "worker booster" * Gitea's queue's handlers are light functions, the cost is only the go-routine, so it doesn't make sense to "boost" them. * The new code only use "max worker number" to limit the concurrent workers. * The new "Push" never blocks forever * Instead of creating more and more blocking goroutines, return an error is more friendly to the server and to the end user. There are more details in code comments: eg: the "Flush" problem, the strange "code.index" hanging problem, the "immediate" queue problem. Almost ready for review. TODO: * [x] add some necessary comments during review * [x] add some more tests if necessary * [x] update documents and config options * [x] test max worker / active worker * [x] re-run the CI tasks to see whether any test is flaky * [x] improve the `handleOldLengthConfiguration` to provide more friendly messages * [x] fine tune default config values (eg: length?) ## Code coverage: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
* Merge setting.InitXXX into one function with options (#24389)Lunny Xiao2023-05-041-4/+4
| | | | This PR will merge 3 Init functions on setting packages as 1 and introduce an options struct.
* Fix incorrect webhook time and use relative-time to display it (#24477)yp053272023-05-031-1/+2
| | | | | | | | | | | Fixes #24414 After click replay this webhook, it will display `now` ![image](https://user-images.githubusercontent.com/18380374/235559399-05a23927-13f5-442d-8f10-2c7cd24022a0.png) --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: Giteabot <teabot@gitea.io>
* Fix incorrect `HookEventType` of pull request review comments (#23650)Zettat1232023-03-243-4/+4
| | | | | `HookEventType` of pull request review comments should be `HookEventPullRequestReviewComment` but some event types are `HookEventPullRequestComment` now.
* Add user webhooks (#21563)KN4CK3R2023-03-101-5/+5
| | | | | | | Currently we can add webhooks for organizations but not for users. This PR adds the latter. You can access it from the current users settings. ![grafik](https://user-images.githubusercontent.com/1666336/197391408-15dfdc23-b476-4d0c-82f7-9bc9b065988f.png)
* Use minio/sha256-simd for accelerated SHA256 (#23052)zeripath2023-02-221-1/+1
| | | | | | | | | | | | minio/sha256-simd provides additional acceleration for SHA256 using AVX512, SHA Extensions for x86 and ARM64 for ARM. It provides a drop-in replacement for crypto/sha256 and if the extensions are not available it falls back to standard crypto/sha256. --------- Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: John Olheiser <john.olheiser@gmail.com>
* Fix intermittent panic in notify issue change content (#23019)zeripath2023-02-201-3/+4
| | | | | | | | Ensure that issue pullrequests are loaded before trying to set the self-reference. Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: delvh <leon@kske.dev> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Refactor the setting to make unit test easier (#22405)Lunny Xiao2023-02-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | Some bugs caused by less unit tests in fundamental packages. This PR refactor `setting` package so that create a unit test will be easier than before. - All `LoadFromXXX` files has been splited as two functions, one is `InitProviderFromXXX` and `LoadCommonSettings`. The first functions will only include the code to create or new a ini file. The second function will load common settings. - It also renames all functions in setting from `newXXXService` to `loadXXXSetting` or `loadXXXFrom` to make the function name less confusing. - Move `XORMLog` to `SQLLog` because it's a better name for that. Maybe we should finally move these `loadXXXSetting` into the `XXXInit` function? Any idea? --------- Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: delvh <dev.lh@web.de>
* Add context cache as a request level cache (#22294)Lunny Xiao2023-02-151-45/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Webhooks: for issue close/reopen action, add commit ID that caused it (#22583)Brecht Van Lommel2023-01-241-1/+3
| | | | | | | | The `commit_id` property name is the same as equivalent functionality in GitHub. If the action was not caused by a commit, an empty string is used. This can for example be used to automatically add a Resolved label to an issue fixed by a commit, or clear it when the issue is reopened.
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-12 02:48:27 +0000