(cherry picked from commit 8b11cab677503be78b1deb17ed9dd5fb1c823a7d)
(cherry picked from commit be59270696)
(cherry picked from commit e068f8b191585e2910d8a45ea78bfa1b78015bed)
(cherry picked from commit 7855bb0c60b5ec2a972ae04e4515ee5adb19a5e7)
(cherry picked from commit 45c4c8f44383dced75ab83f7c817b52e78968fab)
(cherry picked from commit 89520d67ffe0062e1accd39763e1e7dd5058d83a)
(cherry picked from commit 15eeb417a4b8bb948f888c73e20135c1e0fd1f63)
(cherry picked from commit 6db53a26432f02ae50da948483e2010bd962f9ce)
(cherry picked from commit 2f689b321fa275b6412f0b8686edc7aba97c3565)
(cherry picked from commit 04dc478314c3b4927cca78c354ca46ee217f035a)
(cherry picked from commit a554624f40f51c1c75d754d6cca14f7626bb599e)
(cherry picked from commit abca05f0d1c29680bba897cc0de7037053915ced)
(cherry picked from commit dc13e7eb22f2bde817f3845c646574d8f39c1b18)
(cherry picked from commit a161c5740eb5e76c13354ba2388fa34ae925fd8b)
(cherry picked from commit 06d33e2773f01b576ba050afe2b88718a7999434)
(cherry picked from commit f536275161cc4bf5d2f163bd68a4c4498c9fff3d)
(cherry picked from commit 84ac6f314a1840d45bdecb2ccd4482fb925fd2c2)
(cherry picked from commit 1e8126edfc3a6c78cda35f053bd0ac40ba9874ef)
(cherry picked from commit 0287ac3416563e0af05c3aeabc338b791c74ddb2)
(cherry picked from commit 0efa9205ca8a128614aef5d7ffb07e37058ed7dc)
(cherry picked from commit 7b67c3b095680ce518aa13ca79b96ebe01f414d8)
(cherry picked from commit 60a7cf73e8aeecd673bfc9254a6bfa8d07aeb737)
(cherry picked from commit 540084860a91cf26146c6cfa3ca122b6da5d6e44)
(cherry picked from commit cf8e222c4bcf794ae4983ab54d0062a45d0011b1)
(cherry picked from commit a91971f628)
Replace #22751
1. only support the default branch in the repository setting.
2. autoload schedule data from the schedule table after starting the
service.
3. support specific syntax like `@yearly`, `@monthly`, `@weekly`,
`@daily`, `@hourly`
## How to use
See the [GitHub Actions
document](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)
for getting more detailed information.
```yaml
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
```
Signed-off-by: Bo-Yi.Wu <appleboy.tw@gmail.com>
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Follow #25229
Copy from
https://github.com/go-gitea/gitea/pull/26290#issuecomment-1663135186
The bug is that we cannot get changed files for the
`pull_request_target` event. This event runs in the context of the base
branch, so we won't get any changes if we call
`GetFilesChangedSinceCommit` with `PullRequest.Base.Ref`.
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.
Fix#25736
Caused by #24048
Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
pull_request:
branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.
Co-authored-by: Giteabot <teabot@gitea.io>
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.
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>
Follow #23037
Fix [#22598
comment](https://github.com/go-gitea/gitea/issues/22958#issuecomment-1475763042)
Workflows with `pull_request` trigger event can't be triggered by
`pull_request_sync` event. This PR adds the `canGithubEventMatch`
function to check if a Github event can match any Gitea event. If the
Github event matches a Gitea event, the related workflows should be
triggered.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
caused by #22680
`pushPayload.Ref` and `prPayload.PullRequest.Base.Ref` have the format
like `refs/heads/<branch_name>`, so we need to trim the prefix before
comparing.
#21937 implemented only basic events based on name because of `act`'s
limitation. So I sent a PR to parse all possible events details in
https://gitea.com/gitea/act/pulls/11 and it merged. The ref
documentation is
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
This PR depends on that and make more detail responses for `push` events
and `pull_request` events. And it lefts more events there for future
PRs.
---------
Co-authored-by: Jason Song <i@wolfogre.com>
