Closes #2797
I'm aware of https://github.com/go-gitea/gitea/pull/28163 exists, but since I had it laying around on my drive and collecting dust, I might as well open a PR for it if anyone wants the feature a bit sooner than waiting for upstream to release it or to be a forgejo "native" implementation.
This PR Contains:
- Support for the `workflow_dispatch` trigger
- Inputs: boolean, string, number, choice
Things still to be done:
- [x] API Endpoint `/api/v1/<org>/<repo>/actions/workflows/<workflow id>/dispatches`
- ~~Fixing some UI bugs I had no time figuring out, like why dropdown/choice inputs's menu's behave weirdly~~ Unrelated visual bug with dropdowns inside dropdowns
- [x] Fix bug where opening the branch selection submits the form
- [x] Limit on inputs to render/process
Things not in this PR:
- Inputs: environment (First need support for environments in forgejo)
Things needed to test this:
- A patch for https://code.forgejo.org/forgejo/runner to actually consider the inputs inside the workflow.
~~One possible patch can be seen here: https://code.forgejo.org/Mai-Lapyst/runner/src/branch/support-workflow-inputs~~
[PR](https://code.forgejo.org/forgejo/runner/pulls/199)
## Testing
- Checkout PR
- Setup new development runner with [this PR](https://code.forgejo.org/forgejo/runner/pulls/199)
- Create a repo with a workflow (see below)
- Go to the actions tab, select the workflow and see the notice as in the screenshot above
- Use the button + dropdown to run the workflow
- Try also running it via the api using the `` endpoint
- ...
- Profit!
<details>
<summary>Example workflow</summary>
```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log Level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
boolean_default_true:
description: 'Test scenario tags'
required: true
type: boolean
default: true
boolean_default_false:
description: 'Test scenario tags'
required: false
type: boolean
default: false
number1_default:
description: 'Number w. default'
default: '100'
type: number
number2:
description: 'Number w/o. default'
type: number
string1_default:
description: 'String w. default'
default: 'Hello world'
type: string
string2:
description: 'String w/o. default'
required: true
type: string
jobs:
test:
runs-on: docker
steps:
- uses: actions/checkout@v3
- run: whoami
- run: cat /etc/issue
- run: uname -a
- run: date
- run: echo ${{ inputs.logLevel }}
- run: echo ${{ inputs.tags }}
- env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
- run: echo "abc"
```
</details>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3334
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
do not reuse the payload of the event that triggered the creation of
the scheduled event. Create a new one instead that contains no other
information than the event name in the action field ("schedule").
(cherry picked from commit 0b40ca1ea5)
(cherry picked from commit f86487432b)
(cherry picked from commit 4bd5d2e9d0)
(cherry picked from commit d10830e238)
(cherry picked from commit 53f5a3aa91)
(cherry picked from commit 9ed1487b73)
(cherry picked from commit 6a39978851)
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.
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.
Change all license headers to comply with REUSE specification.
Fix #16132
Co-authored-by: flynnnnnnnnnn <flynnnnnnnnnn@github>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
_This is a different approach to #20267, I took the liberty of adapting
some parts, see below_
## Context
In some cases, a weebhook endpoint requires some kind of authentication.
The usual way is by sending a static `Authorization` header, with a
given token. For instance:
- Matrix expects a `Bearer <token>` (already implemented, by storing the
header cleartext in the metadata - which is buggy on retry #19872)
- TeamCity #18667
- Gitea instances #20267
- SourceHut https://man.sr.ht/graphql.md#authentication-strategies (this
is my actual personal need :)
## Proposed solution
Add a dedicated encrypt column to the webhook table (instead of storing
it as meta as proposed in #20267), so that it gets available for all
present and future hook types (especially the custom ones #19307).
This would also solve the buggy matrix retry #19872.
As a first step, I would recommend focusing on the backend logic and
improve the frontend at a later stage. For now the UI is a simple
`Authorization` field (which could be later customized with `Bearer` and
`Basic` switches):
The header name is hard-coded, since I couldn't fine any usecase
justifying otherwise.
## Questions
- What do you think of this approach? @justusbunsi @Gusted @silverwind
- ~~How are the migrations generated? Do I have to manually create a new
file, or is there a command for that?~~
- ~~I started adding it to the API: should I complete it or should I
drop it? (I don't know how much the API is actually used)~~
## Done as well:
- add a migration for the existing matrix webhooks and remove the
`Authorization` logic there
_Closes #19872_
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Gusted <williamzijl7@hotmail.com>
Co-authored-by: delvh <dev.lh@web.de>
Fixes #21379
The commits are capped by `setting.UI.FeedMaxCommitNum` so
`len(commits)` is not the correct number. So this PR adds a new
`TotalCommits` field.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Add support for triggering webhook notifications on wiki changes.
This PR contains frontend and backend for webhook notifications on wiki actions (create a new page, rename a page, edit a page and delete a page). The frontend got a new checkbox under the Custom Event -> Repository Events section. There is only one checkbox for create/edit/rename/delete actions, because it makes no sense to separate it and others like releases or packages follow the same schema.
The actions itself are separated, so that different notifications will be executed (with the "action" field). All the webhook receivers implement the new interface method (Wiki) and the corresponding tests.
When implementing this, I encounter a little bug on editing a wiki page. Creating and editing a wiki page is technically the same action and will be handled by the ```updateWikiPage``` function. But the function need to know if it is a new wiki page or just a change. This distinction is done by the ```action``` parameter, but this will not be sent by the frontend (on form submit). This PR will fix this by adding the ```action``` parameter with the values ```_new``` or ```_edit```, which will be used by the ```updateWikiPage``` function.
I've done integration tests with matrix and gitea (http).
Fix #16457
Signed-off-by: Aaron Fischer <mail@aaron-fischer.net>
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* Update templates/admin/hook_new.tmpl
Co-authored-by: a1012112796 <1012112796@qq.com>
* Update services/webhook/wechatwork.go
Co-authored-by: a1012112796 <1012112796@qq.com>
* 修善wechatwork
* 修善wechatwork
* fix
* Update locale_cs-CZ.ini
fix
* fix build
* fix
* fix build
* make webhooks.zh-cn.md
* delet unnecessary blank line
* delet unnecessary blank line
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* Update templates/admin/hook_new.tmpl
Co-authored-by: a1012112796 <1012112796@qq.com>
* Update services/webhook/wechatwork.go
Co-authored-by: a1012112796 <1012112796@qq.com>
* 修善wechatwork
* 修善wechatwork
* fix
* fix build
* fix
* fix build
* make webhooks.zh-cn.md
* delet unnecessary blank line
* delet unnecessary blank line
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* fix
* fix
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* fix wechat
* fix wechat
* fix wechat
* fix wechat
* Fix invalid params and typo of email templates (#16394)
Signed-off-by: Meano <meanocat@gmail.com>
* Add LRU mem cache implementation (#16226)
The current default memory cache implementation is unbounded in size and number of
objects cached. This is hardly ideal.
This PR proposes creating a TwoQueue LRU cache as the underlying cache for Gitea.
The cache is limited by the number of objects stored in the cache (rather than size)
for simplicity. The default number of objects is 50000 - which is perhaps too small
as most of our objects cached are going to be much less than 1kB.
It may be worth considering using a different LRU implementation that actively limits
sizes or avoids GC - however, this is just a beginning implementation.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* [skip ci] Updated translations via Crowdin
* Replace `plugins/docker` with `techknowlogick/drone-docker`in ci (#16407)
* plugins/docker -> techknowlogick/drone-docker
* It is multi-arch
* docs: rewrite email setup (#16404)
* Add intro for both the docs page and mailer methods
* Fix numbering level in SMTP section
* Recommends implicit TLS
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
* Validate Issue Index before querying DB (#16406)
* Fix external renderer (#16401)
* fix external renderer
* use GBackground context as fallback
* no fallback, return error
Co-authored-by: Lauris BH <lauris@nix.lv>
* Add checkbox to delete pull branch after successful merge (#16049)
* Add checkbox to delete pull branch after successful merge
* Omit DeleteBranchAfterMerge field in json
* Log a warning instead of error when PR head branch deleted
* Add DefaultDeleteBranchAfterMerge to PullRequestConfig
* Add support for delete_branch_after_merge via API
* Fix for API: the branch should be deleted from the HEAD repo
If head and base repo are the same, reuse the already opened ctx.Repo.GitRepo
* Don't delegate to CleanupBranch, only reuse branch deletion code
CleanupBranch contains too much logic that has already been performed by the Merge
* Reuse gitrepo in MergePullRequest
Co-authored-by: Andrew Thornton <art27@cantab.net>
* [skip ci] Updated translations via Crowdin
* Detect encoding changes while parsing diff (#16330)
* Detect encoding changes while parsing diff
* Let branch/tag name be a valid ref to get CI status (#16400)
* fix #16384#
* refactor: move shared helper func to utils package
* extend Tests
* use ctx.Repo.GitRepo if not nil
* fix
* fix
* 企业微信webhook
* 企业微信webhook
* 企业微信webhook
* fix build
* fix build
* Apply suggestions from code review
Co-authored-by: a1012112796 <1012112796@qq.com>
Co-authored-by: myheavily <myheavily>
Co-authored-by: zhaoxin <gitea@fake.local>
Co-authored-by: Meano <Meano@foxmail.com>
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: GiteaBot <teabot@gitea.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Bagas Sanjaya <bagasdotme@gmail.com>
Co-authored-by: Norwin <noerw@users.noreply.github.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Jimmy Praet <jimmy.praet@telenet.be>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
This PR removes multiple unneeded fields from the `HookTask` struct and adds the two headers `X-Hub-Signature` and `X-Hub-Signature-256`.
## ⚠️ BREAKING ⚠️
* The `Secret` field is no longer passed as part of the payload.
* "Breaking" change (or fix?): The webhook history shows the real called url and not the url registered in the webhook (`deliver.go`@129).
Close #16115
Fixes #7788
Fixes #11755
Co-authored-by: zeripath <art27@cantab.net>
This PR updates golangci-lint to the latest version 1.31.0.
The upgrade introduced a new check for which I've fixed or disabled most cases.
Signed-off-by: kolaente <k@knt.li>
* Adds functionality to change target branch of created pull requests
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Use const instead of var in JavaScript additions
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Check if branches are equal and if PR already exists before changing target branch
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Make sure to check all commits
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Print error messages for user as error flash message
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Disallow changing target branch of closed or merged pull requests
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Resolve conflicts after merge of upstream/master
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Change order of branch select fields
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Removes duplicate check
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Use ctx.Tr for translations
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Recompile JS
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Use correct translation namespace
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Remove redundant if condition
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Moves most change branch logic into pull service
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Completes comment
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Add Ref to ChangesPayload for logging changed target branches
instead of creating a new struct
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Revert changes to go.mod
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Directly use createComment method
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Return 404 if pull request is not found. Move written check up
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Remove variable declaration
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Return client errors on change pull request target errors
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Return error in commit.HasPreviousCommit
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Adds blank line
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Test patch before persisting new target branch
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Update patch before testing (not working)
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Removes patch calls when changeing pull request target
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Removes unneeded check for base name
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Moves ChangeTargetBranch completely to pull service. Update patch status.
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Set webhook mode after errors were validated
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Update PR in one transaction
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Move logic for check if head is equal with branch to pull model
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Adds missing comment and simplify return
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
* Adjust CreateComment method call
Signed-off-by: Mario Lubenka <mario.lubenka@googlemail.com>
This PR fixes #7598 by providing a configurable way of signing commits across the Gitea instance. Per repository configurability and import/generation of trusted secure keys is not provided by this PR - from a security PoV that's probably impossible to do properly. Similarly web-signing, that is asking the user to sign something, is not implemented - this could be done at a later stage however.
## Features
- [x] If commit.gpgsign is set in .gitconfig sign commits and files created through repofiles. (merges should already have been signed.)
- [x] Verify commits signed with the default gpg as valid
- [x] Signer, Committer and Author can all be different
- [x] Allow signer to be arbitrarily different - We still require the key to have an activated email on Gitea. A more complete implementation would be to use a keyserver and mark external-or-unactivated with an "unknown" trust level icon.
- [x] Add a signing-key.gpg endpoint to get the default gpg pub key if available
- Rather than add a fake web-flow user I've added this as an endpoint on /api/v1/signing-key.gpg
- [x] Try to match the default key with a user on gitea - this is done at verification time
- [x] Make things configurable?
- app.ini configuration done
- [x] when checking commits are signed need to check if they're actually verifiable too
- [x] Add documentation
I have decided that adjusting the docker to create a default gpg key is not the correct thing to do and therefore have not implemented this.
