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>
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>
(cherry picked from commit fc2d75f86d77b022ece848acf2581c14ef21d43b)
Conflicts:
modules/setting/config_env.go
modules/storage/azureblob.go
services/webhook/dingtalk.go
services/webhook/discord.go
services/webhook/feishu.go
services/webhook/matrix.go
services/webhook/msteams.go
services/webhook/packagist.go
services/webhook/slack.go
services/webhook/telegram.go
services/webhook/wechatwork.go
run make lint-go and fix Forgejo specific warnings
Fix#25897Fix#30322#29464 cannot handle some complex `if` conditions correctly because it
only checks `always()` literally. In fact, it's not easy to evaluate the
`if` condition on the Gitea side because evaluating it requires a series
of contexts. But act_runner is able to evaluate the `if` condition
before running the job (for more information, see
[`gitea/act`](517d11c671/pkg/runner/run_context.go (L739-L753)))
. So we can use act_runner to check the `if` condition.
In this PR, how to handle a blocked job depends on its `needs` and `if`:
- If not all jobs in `needs` completed successfully and the job's `if`
is empty, set the job status to `StatusSkipped`
- In other cases, the job status will be set to `StatusWaiting`, and
then act_runner will check the `if` condition and run the job if the
condition is met
(cherry picked from commit 31a0c4dfb4156a7b4d856cceae1e61c7fc1a4a1b)
- Add endpoint to list repository action secrets in API routes
- Implement `ListActionsSecrets` function to retrieve action secrets
from the database
- Update Swagger documentation to include the new
`/repos/{owner}/{repo}/actions/secrets` endpoint
- Add `actions` package import and define new routes for actions,
secrets, variables, and runners in `api.go`.
- Refactor action-related API functions into `Action` struct methods in
`org/action.go` and `repo/action.go`.
- Remove `actionAPI` struct and related functions, replacing them with
`NewAction()` calls.
- Rename `variables.go` to `action.go` in `org` directory.
- Delete `runners.go` and `secrets.go` in both `org` and `repo`
directories, consolidating their content into `action.go`.
- Update copyright year and add new imports in `org/action.go`.
- Implement `API` interface in `services/actions/interface.go` for
action-related methods.
- Remove individual action-related functions and replace them with
methods on the `Action` struct in `repo/action.go`.
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Signed-off-by: appleboy <appleboy.tw@gmail.com>
(cherry picked from commit 852547d0dc70299589c7bf8d00ea462ed709b8e5)
Conflicts:
routers/api/v1/api.go
trivial conflict because of Fix#2512 /api/forgejo/v1/version auth check (#2582)
Follow #29468
1. Interpolate runs-on with variables when scheduling tasks.
2. The `GetVariablesOfRun` function will check if the `Repo` of the run
is nil.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 2f6b1c46a1a4a90f56ca0f3ad7840e8e70daeab5)
Conflicts:
services/actions/schedule_tasks.go
trivial conflict because of 'Add vars context to cron jobs (#3059)'
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`.
(cherry picked from commit 74f0c84fa4245a20ce6fb87dac1faf2aeeded2a2)
Conflicts:
.golangci.yml
apply the linter recommendations to Forgejo code as well
Follow https://github.com/go-gitea/gitea/pull/30357
When user push to default branch, the schedule trigger user will be the
user.
When disable then enable action units in settings, the schedule trigger
user will be action user.
When repo is a mirror, the schedule trigger user will be action user. (
before it will return error, fixed by #30357)
As scheduled job is a cron, the trigger user should be action user from
Gitea, not a real user.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit cb6814adad4dc81a683b50826a211ce7bce731d7)
Conflicts:
- services/actions/notifier_helper.go
Conflict resolved by keeping Forgejo's version of the line.
Since https://github.com/go-gitea/gitea/pull/25686, a few `interface{}`
have sneaked into the codebase. Add this replacement to `make fmt` to
prevent this from happening again.
Ideally a linter would do this, but I haven't found any suitable.
(cherry picked from commit c77e8140bc2ac6521dbebfb77613dce2648bfcb8)
Conflicts:
- .gitattributes
Trivial conflict resolved by picking our choice of language
for `*.tmpl` files.
When repo is a mirror, and commit author is an external user, then
`GetUserByEmail` will return error.
reproduce/test:
- mirror Gitea to your instance
- disable action and enable it again, this will trigger
`DetectAndHandleSchedules`
ps: also follow #24706, it only fixed normal runs, not scheduled runs.
(cherry picked from commit 96d31fe0a8b88c09488989cd5459d4124dcb7983)
The user that caused the notification to re-evaluates the
schedules is not the one that will trigger the workflows. They are
background tasks that are authored by the action user (id -2).
Such a mis-assignment is problematic when the user that caused the
notification is deleted.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3211
(cherry picked from commit f8ab9dafb7a173a35e9308f8f784735b0f822439)
Conflicts:
routers/web/repo/fork.go
trivial context conflict, the file does not exist in Forgejo
Fix#28761Fix#27884Fix#28093
## Changes
### Rerun all jobs
When rerun all jobs, status of the jobs with `needs` will be set to
`blocked` instead of `waiting`. Therefore, these jobs will not run until
the required jobs are completed.
### Rerun a single job
When a single job is rerun, its dependents should also be rerun, just
like GitHub does
(https://github.com/go-gitea/gitea/issues/28761#issuecomment-2008620820).
In this case, only the specified job will be set to `waiting`, its
dependents will be set to `blocked` to wait the job.
### Show warning if every job has `needs`
If every job in a workflow has `needs`, all jobs will be blocked and no
job can be run. So I add a warning message.
<img
src="https://github.com/go-gitea/gitea/assets/15528715/88f43511-2360-465d-be96-ee92b57ff67b"
width="480px" />
(cherry picked from commit 2f060c5834d81f0317c795fc281f9a07e03e5962)
Fix#29731
Caused by #24634
Also remove fixme.
ps: we can not fix the existed runs, as wrong refs are all recorded in
DB, and we can not know whether they are branch or tag:
(cherry picked from commit 98217b034076157547cf688cc10f47cd3275c872)
Conflicts:
tests/integration/actions_trigger_test.go
there is a need for more imports because the exist tests
are done differently, using CreateDeclarativeRepo
Fix#29040
`handleSchedules` should be called only if `DetectWorkflows` should
detect schedule workflows
(cherry picked from commit e600c35f066c79b717dc0c416b07d5c34502d286)
In #28691, schedule plans will be deleted when a repo's actions unit is
disabled. But when the unit is enabled, the schedule plans won't be
created again.
This PR fixes the bug. The schedule plans will be created again when the
actions unit is re-enabled
(cherry picked from commit adc3598a75)
Fix#28157
This PR fix the possible bugs about actions schedule.
- Move `UpdateRepositoryUnit` and `SetRepoDefaultBranch` from models to
service layer
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when actions unit has been disabled
or global disabled.
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when default branch changed.
(cherry picked from commit 97292da960)
Conflicts:
modules/actions/github.go
routers/web/repo/setting/default_branch.go
routers/web/repo/setting/setting.go
services/repository/branch.go
services/repository/setting.go
tests/integration/actions_trigger_test.go
Also resolves a warning for current releases
```
| ##[group]GitHub Actions runtime token ACs
| ##[warning]Cannot parse GitHub Actions Runtime Token ACs: "undefined" is not valid JSON
| ##[endgroup]
====>
| ##[group]GitHub Actions runtime token ACs
| ##[endgroup]
```
\* this is an error in v3
References in the docker org:
-
831ca179d3/src/main.ts (L24)
-
7d8b4dc669/src/github.ts (L61)
No known official action of GitHub makes use of this claim.
Current releases throw an error when configure to use actions cache
```
| ERROR: failed to solve: failed to configure gha cache exporter: invalid token without access controls
| ##[error]buildx failed with: ERROR: failed to solve: failed to configure gha cache exporter: invalid token without access controls
```
(cherry picked from commit 368743baf3d904f86b553a88718583906f571c87)
1. Fix incorrect `HookEventType` for issue-related events in
`IssueChangeAssignee`
2. Add `case "types"` in the `switch` block in `matchPullRequestEvent`
to avoid warning logs
(cherry picked from commit 1ad4bb9eb7641a552c5b88a43eb91d59ec5c0edf)
Fix#27906
According to GitHub's
[documentation](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds),
a job should always run when its `if` is `always()`
> If you would like a job to run even if a job it is dependent on did
not succeed, use the `always()` conditional expression in
`jobs.<job_id>.if`.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit d0fe6ea4e101198911383058a2e121e384934a9c)
Fix#29175
Replace #29207
This PR makes some improvements to the `issue_comment` workflow trigger
event.
1. Fix the bug that pull requests cannot trigger `issue_comment`
workflows
2. Previously the `issue_comment` event only supported the `created`
activity type. This PR adds support for the missing `edited` and
`deleted` activity types.
3. Some events (including `issue_comment`, `issues`, etc. ) only trigger
workflows that belong to the workflow file on the default branch. This
PR introduces the `IsDefaultBranchWorkflow` function to check for these
events.
(cherry picked from commit a4fe1cdf38f9a063e44b197ef07e4260f731c919)
Conflicts:
modules/actions/github.go
context
https://github.com/go-gitea/gitea/pull/27172#discussion_r1493735466
When cleanup artifacts, it removes storage first. If storage is not
exist (maybe delete manually), it gets error and continue loop. It makes
a dead loop if there are a lot pending but non-existing artifacts.
Now it updates db record at first to avoid keep a lot of pending status
artifacts.
Fix#29166
Add support for the following activity types of `pull_request`
- assigned
- unassigned
- review_requested
- review_request_removed
- milestoned
- demilestoned
(cherry picked from commit 1a6e1cbada27db1e3327b0d7d331492c95e24759)
Port of https://github.com/go-gitea/gitea/pull/29205
Use a clearly defined "signing secret" for token signing.
(cherry picked from commit 8be198cdef0a486f417663b1fd6878458d7e5d92)
Skip a HookEventPullRequestSync event if it has the same CommitSHA as an existing HookEventPullRequest event in the ActionRun table. A HookEventPullRequestSync event must only create an ActionRun if the CommitSHA is different from what it was when the PR was open.
This guards against a race that can happen when the following is done in parallel:
* A commit C is pushed to a repo on branch B
* A pull request with head on branch B
it is then possible that the pull request is created first, successfully. The commit that was just pushed is not known yet but the PR only references the repository and the B branch so it is fine.
A HookEventPullRequest event is sent to the notification queue but not processed immediately.
The commit C is pushed and processed successfully. Since the PR already exists and has a head that matches the branch, the head of the PR is updated with the commit C and a HookEventPullRequestSync event is sent to the notification queue.
The HookEventPullRequest event is processed and since the head of the PR was updated to be commit C, an ActionRun with CommitSHA C is created.
The HookEventPullRequestSync event is then processed and also has a CommitSHA equal to C.
Refs: https://codeberg.org/forgejo/forgejo/issues/2009
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2314
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
handleSchedules() is called every time an event is received and will
check the content of the main branch to (re)create scheduled events.
There is no reason why intput.Event will be relevant when the schedule
workflow runs.
(cherry picked from commit 9a712bb276)
(cherry picked from commit 41af36da81)
(cherry picked from commit bb83604fa2)
(cherry picked from commit 65e4503a7a)
(cherry picked from commit e562b6f7a0)
(cherry picked from commit aca2ae2390)
(cherry picked from commit bf2b5ea507)
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)
This change allows act_runner / actions_runner to use jwt tokens for
`ACTIONS_RUNTIME_TOKEN` that are compatible with
actions/upload-artifact@v4.
The official Artifact actions are now validating and extracting the jwt
claim scp to get the runid and jobid, the old artifact backend also
needs to accept the same token jwt.
---
Related to #28853
I'm not familar with the auth system, maybe you know how to improve this
I have tested
- the jwt token is a valid token for artifact uploading
- the jwt token can be parsed by actions/upload-artifact@v4 and passes
their scp claim validation
Next steps would be a new artifacts@v4 backend.
~~I'm linking the act_runner change soonish.~~
act_runner change to make the change effective and use jwt tokens
<https://gitea.com/gitea/act_runner/pulls/471>
