jojo/modules/actions/workflows_test.go

407 lines
14 KiB
Go
Raw Normal View History

Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
// Copyright 2023 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT
package actions
import (
feat(actions): make GITHUB_WORKFLOW_REF available (#10276) Make the variable `GITHUB_WORKFLOW_REF` available in Forgejo Action workflows. It is the ref path to the workflow and looks like `testowner/testrepo/.forgejo/workflows/test-workflow.yaml@refs/heads/main` ([GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)). GitHub Actions like [gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) rely on its presence. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/56 for additional details. `GITHUB_WORKFLOW_REF` cannot be generated easily during an action run. Either the path to workflow file has to be hardcoded or inferred by replicating the logic Forgejo uses to determine it. That is further complicated by the fact that Forgejo supports multiple search paths, namely `.forgejo/workflows`, `.gitea/workflows`, and `.github/workflows`. It is also the reason that the workflow directory is now stored in the database alongside the name of the workflow file. Partial implementation is required in Forgejo Runner, see https://code.forgejo.org/forgejo/runner/pulls/1197. Example workflow: ```yaml on: push: workflow_dispatch: schedule: - cron: "* * * * *" jobs: test: runs-on: ubuntu-latest steps: - run: | echo "FORGEJO_WORKFLOW_REF=$FORGEJO_WORKFLOW_REF" echo "GITHUB_WORKFLOW_REF=$GITHUB_WORKFLOW_REF" echo "forgejo.workflow_ref=${{ forgejo.workflow_ref }}" echo "github.workflow_ref=${{ github.workflow_ref }}" ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10276 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2025-12-17 23:15:26 +01:00
"os"
"path/filepath"
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
"testing"
feat(actions): make GITHUB_WORKFLOW_REF available (#10276) Make the variable `GITHUB_WORKFLOW_REF` available in Forgejo Action workflows. It is the ref path to the workflow and looks like `testowner/testrepo/.forgejo/workflows/test-workflow.yaml@refs/heads/main` ([GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)). GitHub Actions like [gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) rely on its presence. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/56 for additional details. `GITHUB_WORKFLOW_REF` cannot be generated easily during an action run. Either the path to workflow file has to be hardcoded or inferred by replicating the logic Forgejo uses to determine it. That is further complicated by the fact that Forgejo supports multiple search paths, namely `.forgejo/workflows`, `.gitea/workflows`, and `.github/workflows`. It is also the reason that the workflow directory is now stored in the database alongside the name of the workflow file. Partial implementation is required in Forgejo Runner, see https://code.forgejo.org/forgejo/runner/pulls/1197. Example workflow: ```yaml on: push: workflow_dispatch: schedule: - cron: "* * * * *" jobs: test: runs-on: ubuntu-latest steps: - run: | echo "FORGEJO_WORKFLOW_REF=$FORGEJO_WORKFLOW_REF" echo "GITHUB_WORKFLOW_REF=$GITHUB_WORKFLOW_REF" echo "forgejo.workflow_ref=${{ forgejo.workflow_ref }}" echo "github.workflow_ref=${{ github.workflow_ref }}" ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10276 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2025-12-17 23:15:26 +01:00
"time"
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
"forgejo.org/modules/git"
feat(actions): make GITHUB_WORKFLOW_REF available (#10276) Make the variable `GITHUB_WORKFLOW_REF` available in Forgejo Action workflows. It is the ref path to the workflow and looks like `testowner/testrepo/.forgejo/workflows/test-workflow.yaml@refs/heads/main` ([GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)). GitHub Actions like [gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) rely on its presence. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/56 for additional details. `GITHUB_WORKFLOW_REF` cannot be generated easily during an action run. Either the path to workflow file has to be hardcoded or inferred by replicating the logic Forgejo uses to determine it. That is further complicated by the fact that Forgejo supports multiple search paths, namely `.forgejo/workflows`, `.gitea/workflows`, and `.github/workflows`. It is also the reason that the workflow directory is now stored in the database alongside the name of the workflow file. Partial implementation is required in Forgejo Runner, see https://code.forgejo.org/forgejo/runner/pulls/1197. Example workflow: ```yaml on: push: workflow_dispatch: schedule: - cron: "* * * * *" jobs: test: runs-on: ubuntu-latest steps: - run: | echo "FORGEJO_WORKFLOW_REF=$FORGEJO_WORKFLOW_REF" echo "GITHUB_WORKFLOW_REF=$GITHUB_WORKFLOW_REF" echo "forgejo.workflow_ref=${{ forgejo.workflow_ref }}" echo "github.workflow_ref=${{ github.workflow_ref }}" ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10276 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2025-12-17 23:15:26 +01:00
"forgejo.org/modules/setting"
api "forgejo.org/modules/structs"
feat(actions): make GITHUB_WORKFLOW_REF available (#10276) Make the variable `GITHUB_WORKFLOW_REF` available in Forgejo Action workflows. It is the ref path to the workflow and looks like `testowner/testrepo/.forgejo/workflows/test-workflow.yaml@refs/heads/main` ([GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)). GitHub Actions like [gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) rely on its presence. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/56 for additional details. `GITHUB_WORKFLOW_REF` cannot be generated easily during an action run. Either the path to workflow file has to be hardcoded or inferred by replicating the logic Forgejo uses to determine it. That is further complicated by the fact that Forgejo supports multiple search paths, namely `.forgejo/workflows`, `.gitea/workflows`, and `.github/workflows`. It is also the reason that the workflow directory is now stored in the database alongside the name of the workflow file. Partial implementation is required in Forgejo Runner, see https://code.forgejo.org/forgejo/runner/pulls/1197. Example workflow: ```yaml on: push: workflow_dispatch: schedule: - cron: "* * * * *" jobs: test: runs-on: ubuntu-latest steps: - run: | echo "FORGEJO_WORKFLOW_REF=$FORGEJO_WORKFLOW_REF" echo "GITHUB_WORKFLOW_REF=$GITHUB_WORKFLOW_REF" echo "forgejo.workflow_ref=${{ forgejo.workflow_ref }}" echo "github.workflow_ref=${{ github.workflow_ref }}" ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10276 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2025-12-17 23:15:26 +01:00
"forgejo.org/modules/test"
webhook_module "forgejo.org/modules/webhook"
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
)
feat: show workflow name for scheduled runs (#11770) Previously, a scheduled run would appear like a run triggered by a push. That could be confusing, especially if a scheduled run was unrelated to that particular commit. Now, either the workflow's name (taken from the field `name:`) is displayed or the path to workflow file, matching the behaviour of `workflow_dispatch`. As a side-effect, the description of all run types were improved. They are no longer pieced together from individual translations. `workflow_dispatch` also no longer misattributes commits to the user that triggered the workflow. Resolves https://codeberg.org/forgejo/forgejo/issues/11688. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests for Go changes (can be removed for JavaScript changes) - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes (can be removed for Go changes) - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11770 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2026-03-24 01:27:32 +01:00
func TestDetectedWorkflowGetWorkflowPath(t *testing.T) {
buildWorkflow := DetectedWorkflow{EntryDirectory: ".github/workflows", EntryName: "build.yaml"}
testWorkflow := DetectedWorkflow{EntryDirectory: ".forgejo/workflows", EntryName: "test.yaml"}
assert.Equal(t, ".github/workflows/build.yaml", buildWorkflow.GetWorkflowPath())
assert.Equal(t, ".forgejo/workflows/test.yaml", testWorkflow.GetWorkflowPath())
}
feat(actions): make GITHUB_WORKFLOW_REF available (#10276) Make the variable `GITHUB_WORKFLOW_REF` available in Forgejo Action workflows. It is the ref path to the workflow and looks like `testowner/testrepo/.forgejo/workflows/test-workflow.yaml@refs/heads/main` ([GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)). GitHub Actions like [gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) rely on its presence. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/56 for additional details. `GITHUB_WORKFLOW_REF` cannot be generated easily during an action run. Either the path to workflow file has to be hardcoded or inferred by replicating the logic Forgejo uses to determine it. That is further complicated by the fact that Forgejo supports multiple search paths, namely `.forgejo/workflows`, `.gitea/workflows`, and `.github/workflows`. It is also the reason that the workflow directory is now stored in the database alongside the name of the workflow file. Partial implementation is required in Forgejo Runner, see https://code.forgejo.org/forgejo/runner/pulls/1197. Example workflow: ```yaml on: push: workflow_dispatch: schedule: - cron: "* * * * *" jobs: test: runs-on: ubuntu-latest steps: - run: | echo "FORGEJO_WORKFLOW_REF=$FORGEJO_WORKFLOW_REF" echo "GITHUB_WORKFLOW_REF=$GITHUB_WORKFLOW_REF" echo "forgejo.workflow_ref=${{ forgejo.workflow_ref }}" echo "github.workflow_ref=${{ github.workflow_ref }}" ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10276 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2025-12-17 23:15:26 +01:00
func TestActionsWorkflowsDetectMatched(t *testing.T) {
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
testCases := []struct {
2024-07-31 00:15:22 +02:00
desc string
commit *git.Commit
triggeredEvent webhook_module.HookEventType
payload api.Payloader
yamlOn string
expected bool
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
}{
{
2024-07-31 00:15:22 +02:00
desc: "HookEventCreate(create) matches GithubEventCreate(create)",
triggeredEvent: webhook_module.HookEventCreate,
payload: nil,
yamlOn: "on: create",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventIssues(issues) `opened` action matches GithubEventIssues(issues)",
triggeredEvent: webhook_module.HookEventIssues,
payload: &api.IssuePayload{Action: api.HookIssueOpened},
yamlOn: "on: issues",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventIssueComment(issue_comment) `created` action matches GithubEventIssueComment(issue_comment)",
triggeredEvent: webhook_module.HookEventIssueComment,
payload: &api.IssueCommentPayload{Action: api.HookIssueCommentCreated},
yamlOn: "on:\n issue_comment:\n types: [created]",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
2024-07-31 00:15:22 +02:00
{
desc: "HookEventIssues(issues) `milestoned` action matches GithubEventIssues(issues)",
triggeredEvent: webhook_module.HookEventIssues,
payload: &api.IssuePayload{Action: api.HookIssueMilestoned},
yamlOn: "on: issues",
expected: true,
},
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequestSync(pull_request_sync) matches GithubEventPullRequest(pull_request)",
triggeredEvent: webhook_module.HookEventPullRequestSync,
payload: &api.PullRequestPayload{Action: api.HookIssueSynchronized},
yamlOn: "on: pull_request",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequest(pull_request) `label_updated` action doesn't match GithubEventPullRequest(pull_request) with no activity type",
triggeredEvent: webhook_module.HookEventPullRequest,
payload: &api.PullRequestPayload{Action: api.HookIssueLabelUpdated},
yamlOn: "on: pull_request",
expected: false,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequest(pull_request) `closed` action doesn't match GithubEventPullRequest(pull_request) with no activity type",
triggeredEvent: webhook_module.HookEventPullRequest,
payload: &api.PullRequestPayload{Action: api.HookIssueClosed},
yamlOn: "on: pull_request",
expected: false,
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequest(pull_request) `closed` action doesn't match GithubEventPullRequest(pull_request) with branches",
triggeredEvent: webhook_module.HookEventPullRequest,
payload: &api.PullRequestPayload{
Action: api.HookIssueClosed,
PullRequest: &api.PullRequest{
Base: &api.PRBranchInfo{},
},
},
yamlOn: "on:\n pull_request:\n branches: [main]",
expected: false,
},
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequest(pull_request) `label_updated` action matches GithubEventPullRequest(pull_request) with `label` activity type",
triggeredEvent: webhook_module.HookEventPullRequest,
payload: &api.PullRequestPayload{Action: api.HookIssueLabelUpdated},
yamlOn: "on:\n pull_request:\n types: [labeled]",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequestReviewComment(pull_request_review_comment) matches GithubEventPullRequestReviewComment(pull_request_review_comment)",
triggeredEvent: webhook_module.HookEventPullRequestReviewComment,
payload: &api.PullRequestPayload{Action: api.HookIssueReviewed},
yamlOn: "on:\n pull_request_review_comment:\n types: [created]",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventPullRequestReviewRejected(pull_request_review_rejected) doesn't match GithubEventPullRequestReview(pull_request_review) with `dismissed` activity type (we don't support `dismissed` at present)",
triggeredEvent: webhook_module.HookEventPullRequestReviewRejected,
payload: &api.PullRequestPayload{Action: api.HookIssueReviewed},
yamlOn: "on:\n pull_request_review:\n types: [dismissed]",
expected: false,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventRelease(release) `published` action matches GithubEventRelease(release) with `published` activity type",
triggeredEvent: webhook_module.HookEventRelease,
payload: &api.ReleasePayload{Action: api.HookReleasePublished},
yamlOn: "on:\n release:\n types: [published]",
expected: true,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventRelease(updated) `updated` action matches GithubEventRelease(edited) with `edited` activity type",
triggeredEvent: webhook_module.HookEventRelease,
payload: &api.ReleasePayload{Action: api.HookReleaseUpdated},
yamlOn: "on:\n release:\n types: [edited]",
expected: true,
},
{
desc: "HookEventPackage(package) `created` action doesn't match GithubEventRegistryPackage(registry_package) with `updated` activity type",
triggeredEvent: webhook_module.HookEventPackage,
payload: &api.PackagePayload{Action: api.HookPackageCreated},
yamlOn: "on:\n registry_package:\n types: [updated]",
expected: false,
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventWiki(wiki) matches GithubEventGollum(gollum)",
triggeredEvent: webhook_module.HookEventWiki,
payload: nil,
yamlOn: "on: gollum",
expected: true,
},
{
2024-07-31 00:15:22 +02:00
desc: "HookEventSchedule(schedule) matches GithubEventSchedule(schedule)",
triggeredEvent: webhook_module.HookEventSchedule,
payload: nil,
yamlOn: "on: schedule",
expected: true,
},
Add support for workflow_dispatch (#3334) 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) ![image](/attachments/2db50c9e-898f-41cb-b698-43edeefd2573) ## 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>
2024-06-28 05:17:11 +00:00
{
2024-07-31 00:15:22 +02:00
desc: "HookEventWorkflowDispatch(workflow_dispatch) matches GithubEventWorkflowDispatch(workflow_dispatch)",
triggeredEvent: webhook_module.HookEventWorkflowDispatch,
payload: nil,
yamlOn: "on: workflow_dispatch",
expected: true,
Add support for workflow_dispatch (#3334) 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) ![image](/attachments/2db50c9e-898f-41cb-b698-43edeefd2573) ## 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>
2024-06-28 05:17:11 +00:00
},
[gitea] week 2025-22 cherry pick (gitea/main -> forgejo) (#8198) ## Checklist - [x] go to the last cherry-pick PR (forgejo/forgejo#8040) to figure out how far it went: [gitea@d5bbaee64e](https://github.com/go-gitea/gitea/commit/d5bbaee64e44327e78e39ad7a1977e21ddc59e1c) - [x] cherry-pick and open PR (forgejo/forgejo#8198) - [ ] have the PR pass the CI - end-to-end (specially important if there are actions related changes) - [ ] add `run-end-to-end` label - [ ] check the result - [ ] write release notes - [ ] assign reviewers - [ ] 48h later, last call - merge 1 hour after the last call ## Legend - :question: - No decision about the commit has been made. - :cherries: - The commit has been cherry picked. - :fast_forward: - The commit has been skipped. - :bulb: - The commit has been skipped, but should be ported to Forgejo. - :writing_hand: - The commit has been skipped, and a port to Forgejo already exists. ## Commits - :cherries: [`gitea`](https://github.com/go-gitea/gitea/commit/17cfae82a5e8357f90701815b11c9bc615d0f7e8) -> [`forgejo`](https://codeberg.org/forgejo/forgejo/commit/6397da88d30de0a470dabadb8e27fbb202d75458) Hide href attribute of a tag if there is no target_url ([gitea#34556](https://github.com/go-gitea/gitea/pull/34556)) - :cherries: [`gitea`](https://github.com/go-gitea/gitea/commit/b408bf2f0bb6e76e73421e63128f08d42047e7c0) -> [`forgejo`](https://codeberg.org/forgejo/forgejo/commit/46bc899d57515fc5349e9113e92da2e4b0d93c75) Fix: skip paths check on tag push events in workflows ([gitea#34602](https://github.com/go-gitea/gitea/pull/34602)) - :cherries: [`gitea`](https://github.com/go-gitea/gitea/commit/9165ea8713adb959b6dda4e64bee1a9b2f818288) -> [`forgejo`](https://codeberg.org/forgejo/forgejo/commit/04332f31bfd8a1c0e8676e4764d44e087f1ccc30) Only activity tab needs heatmap data loading ([gitea#34652](https://github.com/go-gitea/gitea/pull/34652)) - :cherries: [`gitea`](https://github.com/go-gitea/gitea/commit/3f7dbbdaf1dbec3b741b3b883f7e44104e77c80b) -> [`forgejo`](https://codeberg.org/forgejo/forgejo/commit/2a9019fd0491684cdeab6d50a16e5cffaef5508b) Small fix in Pull Requests page ([gitea#34612](https://github.com/go-gitea/gitea/pull/34612)) - :cherries: [`gitea`](https://github.com/go-gitea/gitea/commit/497b83b75d567e6ee867d6be41ce37c4cee74e7e) -> [`forgejo`](https://codeberg.org/forgejo/forgejo/commit/9a83cc7bad79fe79447bf6e3cb3144292f922ebb) Fix migration pull request title too long ([gitea#34577](https://github.com/go-gitea/gitea/pull/34577)) ## TODO - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/6b8b5802185f8ba3cd2d0416cc5640fe758ea532) Refactor container and UI ([gitea#34736](https://github.com/go-gitea/gitea/pull/34736)) Packages: Fix for container, needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/bbee652e293dd761c1d1255a14106e6b9f726003) Prevent duplicate form submissions when creating forks ([gitea#34714](https://github.com/go-gitea/gitea/pull/34714)) Fork: Fix, needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/d21ce9fa0739a954e2ecbc5d2aa1e324b5781a4b) Improve the performance when detecting the file editable ([gitea#34653](https://github.com/go-gitea/gitea/pull/34653)) LFS: Performance improvement - needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/8fed27bf6a8a7582a3b2afcda7842b735f6ea5bd) Fix various problems ([gitea#34708](https://github.com/go-gitea/gitea/pull/34708)) Various: Fixes, tests missing. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/c9505a26b9c4147bc7098e20de732a415669520e) Improve instance wide ssh commit signing ([gitea#34341](https://github.com/go-gitea/gitea/pull/34341)) CodeSign: Nice feature - needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/fbc3796f9e26e38e1ab8624d5d9ab24ccf1ba6ac) Fix pull requests API convert panic when head repository is deleted. ([gitea#34685](https://github.com/go-gitea/gitea/pull/34685)) Pull: Fix, needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/1610a63bfd9e243a0d1ad8a5d05a5ae011a957a9) Fix commit message rendering and some UI problems ([gitea#34680](https://github.com/go-gitea/gitea/pull/34680)) Various Fixes - needs carefull merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/0082cb51fa381338c8f96076f90f9e7a49909f8e) Fix last admin check when syncing users ([gitea#34649](https://github.com/go-gitea/gitea/pull/34649)) oidc: fix "first user is always admin". Needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/c6b2cbd75d290b3b831d9b0ee8b47270e68b273b) Fix footnote jump behavior on the issue page. ([gitea#34621](https://github.com/go-gitea/gitea/pull/34621)) Issues: Fix Markdown rendering. Needs carefull merge ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/7a59f5a8253402d6f98234bf0047ec53156d3af9) Ignore "Close" error when uploading container blob ([gitea#34620](https://github.com/go-gitea/gitea/pull/34620)) No issue, no test. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/6d0b24064a922ee8195a7a7cb858823763bac524) Keeping consistent between UI and API about combined commit status state and fix some bugs ([gitea#34562](https://github.com/go-gitea/gitea/pull/34562)) Next PR in Commit-Status story. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/f6041441ee280faba5f06ec4b7a78c35a402bf87) Refactor FindOrgOptions to use enum instead of bool, fix membership visibility ([gitea#34629](https://github.com/go-gitea/gitea/pull/34629)) Just for a common sense here: How should I consider refactorings? ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/cc942e2a86152939305b30373b618536d46aedca) Fix GetUsersByEmails ([gitea#34643](https://github.com/go-gitea/gitea/pull/34643)) User: Seems to fix email validation - but seems not to be finished. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/7fa5a88831141f9e7b858e282558e786b7e95716) Add `--color-logo` for text that should match logo color ([gitea#34639](https://github.com/go-gitea/gitea/pull/34639)) UI: Nice idea - can we adapt this? ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/47d69b7749689a7a7570ac20bdfd30d336daf7c1) Validate hex colors when creating/editing labels ([gitea#34623](https://github.com/go-gitea/gitea/pull/34623)) Label: Color validation but needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/108db0b04f007a0dc03262cb100aa1fe7b80e785) Fix possible pull request broken when leave the page immediately after clicking the update button ([gitea#34509](https://github.com/go-gitea/gitea/pull/34509)) Nice fix for a bug hard to trace down. Needs careful merge & think about whether a test is possible. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/79cc3698928cdddec433199ac4d9339b4bfcde7d) Fix issue label delete incorrect labels webhook payload ([gitea#34575](https://github.com/go-gitea/gitea/pull/34575)) Small fix but would expect a test, showing what was fixed. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/fe57ee3074c1d6421845bce67e9c580a14e2529e) fixed incorrect page navigation with up and down arrow on last item of dashboard repos ([gitea#34570](https://github.com/go-gitea/gitea/pull/34570)) Small & simple - but tests are missing. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/4e471487fbc680c89985d6afa10724e53739ae8b) Remove unnecessary duplicate code ([gitea#34552](https://github.com/go-gitea/gitea/pull/34552)) Fix arround "Split GetLatestCommitStatus". ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/c5e78fc7addd29b8949883134bc0d5339f64341e) Do not mutate incoming options to SearchRepositoryByName ([gitea#34553](https://github.com/go-gitea/gitea/pull/34553)) Large refactoring to simplify options handling. But needs careful merge. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/f48c0135a611bd8e59b4262c9d2514bda6bb91c1) Fix/improve avatar sync from LDAP ([gitea#34573](https://github.com/go-gitea/gitea/pull/34573)) Nice fix but needs test. ------ - :bulb: [`gitea`](https://github.com/go-gitea/gitea/commit/e8d8984f7c2c49c91bb24ac9c0d86e92a8ec795a) Fix some trivial problems ([gitea#34579](https://github.com/go-gitea/gitea/pull/34579)) Various fixes, tests missing. ------ ## Skipped - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/637070e07bd34c914162cc479aa1683507d9cb14) Fix container range bug ([gitea#34725](https://github.com/go-gitea/gitea/pull/34725)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/0d3e9956cd73b78514a0507eb05446dcc9b7b8cc) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/28debdbe00a51ae031d539f95919351032254695) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/dcc9206a597e9f77a9ecedb0201f48af1e64f258) Raise minimum Node.js version to 20, test on 24 ([gitea#34713](https://github.com/go-gitea/gitea/pull/34713)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/bc28654b49e7bea0ee3088977c86b29b5c032fca) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/65986f423fd7718e8c0afc68261d2655bf60571c) Refactor embedded assets and drop unnecessary dependencies ([gitea#34692](https://github.com/go-gitea/gitea/pull/34692)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/18bafcc3785e0afe66b8c1188bb940eb5bb864a6) Bump minimum go version to 1.24.4 ([gitea#34699](https://github.com/go-gitea/gitea/pull/34699)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/8d135ef5cf2cd64ae7311ef23469689ed333de9d) Update JS deps ([gitea#34701](https://github.com/go-gitea/gitea/pull/34701)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/d5893ee260d6fa7cb1919748555fc1d69b9145cb) Fix markdown wrap ([gitea#34697](https://github.com/go-gitea/gitea/pull/34697)) - gitea UI specific specific ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/06ccb3a1d46433aa0dda24f697f7586f3024c032) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/94db956e319232b35a12d4f2e186b188a88a1be2) frontport changelog ([gitea#34689](https://github.com/go-gitea/gitea/pull/34689)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/d5afdccde82e7f00e54d140533308fe76bf41783) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/e9f5105e9502c4cedd19b7f6dde02adee8caff2a) Migrate to urfave v3 ([gitea#34510](https://github.com/go-gitea/gitea/pull/34510)) already in Forgejo - see https://codeberg.org/forgejo/forgejo/pulls/8035 ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/2c341b6803622772619621e2620755a0ddce07e8) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/92e7e98c565235cd24db82679aa801dace2d1bd8) Update x/crypto package and make builtin SSH use default parameters ([gitea#34667](https://github.com/go-gitea/gitea/pull/34667)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/7b39c8258779363e2071b6171726166c58f843ae) Fix "oras" OCI client compatibility ([gitea#34666](https://github.com/go-gitea/gitea/pull/34666)) Already in forgejo - see https://codeberg.org/forgejo/forgejo/issues/8070 ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/1fe652cd2697b5bb459741f988782163a091c6c8) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/a9a705f4db95dfcfd21a0ad4fcb8f6a7a8809ff5) Fix missed merge commit sha and time when migrating from codecommit ([gitea#34645](https://github.com/go-gitea/gitea/pull/34645)) Migration: Seems to be an important fix, but no tests. As I know @earl-warren worked hard on migration, is this still relevant to us? ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/1e0758a9f1aade415de434163bb0f6363dc6ca50) [skip ci] Updated translations via Crowdin ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/f6f6aedd4fe918df7b5b3593dd1a4e65f6b2ae10) Update JS deps, regenerate SVGs ([gitea#34640](https://github.com/go-gitea/gitea/pull/34640)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/aa2b3b2b1fdaf37917014770cd6bef3a2a5028a3) Misc CSS fixes ([gitea#34638](https://github.com/go-gitea/gitea/pull/34638)) - gitea UI specific specific ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/b38f2d31fdcd1fc5facda86be33d3f830503f538) add codecommit to supported services in api docs ([gitea#34626](https://github.com/go-gitea/gitea/pull/34626)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/74a0178c6a9c28da6ab76545b466ed68c569eb75) add openssh-keygen to rootless image ([gitea#34625](https://github.com/go-gitea/gitea/pull/34625)) already in Forgejo - see https://codeberg.org/forgejo/forgejo/issues/6896 ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/5b22af4373c3936a951dd91da38860a830fcf743) bump to alpine 3.22 ([gitea#34613](https://github.com/go-gitea/gitea/pull/34613)) ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/9e0e107d236022d550d077da7aa9af415ac02f8a) Fix notification count positioning for variable-width elements ([gitea#34597](https://github.com/go-gitea/gitea/pull/34597)) - gitea UI specific specific ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/e5781cec75d7ba350fb9162b3882192574c80429) Fix margin issue in markup paragraph rendering ([gitea#34599](https://github.com/go-gitea/gitea/pull/34599)) - gitea UI specific specific ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/375dab111198e6432b303a3c29b8e91bec95d361) Make pull request and issue history more compact ([gitea#34588](https://github.com/go-gitea/gitea/pull/34588)) - gitea UI specific specific ------ - :fast_forward: [`gitea`](https://github.com/go-gitea/gitea/commit/2a1585b32ea2c3cb961cd1aedf4117d880255a53) Refactor some tests ([gitea#34580](https://github.com/go-gitea/gitea/pull/34580)) ------ <details> <summary><h2>Stats</h2></summary> <br> Between [`gitea@d5bbaee64e`](https://github.com/go-gitea/gitea/commit/d5bbaee64e44327e78e39ad7a1977e21ddc59e1c) and [`gitea@6b8b580218`](https://github.com/go-gitea/gitea/commit/6b8b5802185f8ba3cd2d0416cc5640fe758ea532), **55** commits have been reviewed. We picked **5**, skipped **28** (of which **3** were already in Forgejo!), and decided to port **22**. </details> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: NorthRealm <155140859+NorthRealm@users.noreply.github.com> Co-authored-by: TheFox0x7 <thefox0x7@gmail.com> Co-authored-by: endo0911engineer <161911062+endo0911engineer@users.noreply.github.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8198 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de> Co-committed-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
2025-06-17 18:28:07 +02:00
{
desc: "push to tag matches workflow with paths condition (should skip paths check)",
triggeredEvent: webhook_module.HookEventPush,
payload: &api.PushPayload{
Ref: "refs/tags/v1.0.0",
Before: "0000000",
Commits: []*api.PayloadCommit{
{
ID: "abcdef123456",
Added: []string{"src/main.go"},
Message: "Release v1.0.0",
},
},
},
commit: nil,
yamlOn: "on:\n push:\n paths:\n - src/**",
expected: true,
},
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
}
for _, tc := range testCases {
t.Run(tc.desc, func(t *testing.T) {
evts, err := GetEventsFromContent([]byte(tc.yamlOn))
require.NoError(t, err)
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
assert.Len(t, evts, 1)
2024-07-31 00:15:22 +02:00
assert.Equal(t, tc.expected, detectMatched(nil, tc.commit, tc.triggeredEvent, tc.payload, evts[0]))
Fix mismatch between hook events and github event types (#24048) Some workflow trigger events can have multiple activity types, such as `issues` and `pull_request`, and user can specify which types can trigger the workflow. See GitHub documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows Now some hook events cannot match the workflow trigger events correctly because we don't check the activity types. For example, `pull_request_label` is an individual hook event. But there isn't a `pull_request_label` workflow trigger event, we can only use `pull_request` event's `label` activity type. If we don't check the activity types, the workflows without the `label` activity type may be triggered by the `pull_request_label` event by mistake. We need to improve the match logic. - [x] [`issues` ](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issues) - [x] [`issue_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment) - [x] [`pull_request`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) - [x] [`pull_request_review`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review) - [x] [`pull_request_review_comment`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_review_comment) - [x] [`release`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) - [x] [`registry_package`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#registry_package)
2023-04-13 00:16:47 +08:00
})
}
}
feat(actions): make GITHUB_WORKFLOW_REF available (#10276) Make the variable `GITHUB_WORKFLOW_REF` available in Forgejo Action workflows. It is the ref path to the workflow and looks like `testowner/testrepo/.forgejo/workflows/test-workflow.yaml@refs/heads/main` ([GitHub documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)). GitHub Actions like [gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) rely on its presence. See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/56 for additional details. `GITHUB_WORKFLOW_REF` cannot be generated easily during an action run. Either the path to workflow file has to be hardcoded or inferred by replicating the logic Forgejo uses to determine it. That is further complicated by the fact that Forgejo supports multiple search paths, namely `.forgejo/workflows`, `.gitea/workflows`, and `.github/workflows`. It is also the reason that the workflow directory is now stored in the database alongside the name of the workflow file. Partial implementation is required in Forgejo Runner, see https://code.forgejo.org/forgejo/runner/pulls/1197. Example workflow: ```yaml on: push: workflow_dispatch: schedule: - cron: "* * * * *" jobs: test: runs-on: ubuntu-latest steps: - run: | echo "FORGEJO_WORKFLOW_REF=$FORGEJO_WORKFLOW_REF" echo "GITHUB_WORKFLOW_REF=$GITHUB_WORKFLOW_REF" echo "forgejo.workflow_ref=${{ forgejo.workflow_ref }}" echo "github.workflow_ref=${{ github.workflow_ref }}" ``` ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [ ] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10276 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch> Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
2025-12-17 23:15:26 +01:00
func TestActionsWorkflowsListWorkflowsReturnsNoWorkflowsIfThereAreNone(t *testing.T) {
t.Cleanup(test.MockVariableValue(&setting.Git.HomePath, t.TempDir()))
require.NoError(t, git.InitSimple(t.Context()))
committer := git.Signature{
Email: "jane@example.com",
Name: "Jane",
When: time.Now(),
}
repoHome := t.TempDir()
require.NoError(t, os.WriteFile(filepath.Join(repoHome, "README.md"), []byte("My project"), 0o644))
require.NoError(t, git.InitRepository(t.Context(), repoHome, false, git.Sha1ObjectFormat.Name()))
require.NoError(t, git.AddChanges(repoHome, true))
require.NoError(t, git.CommitChanges(repoHome, git.CommitChangesOptions{Message: "Import", Committer: &committer}))
gitRepo, err := git.OpenRepository(t.Context(), repoHome)
require.NoError(t, err)
defer gitRepo.Close()
headBranch, err := gitRepo.GetHEADBranch()
require.NoError(t, err)
lastCommitID, err := gitRepo.GetBranchCommitID(headBranch.Name)
require.NoError(t, err)
lastCommit, err := gitRepo.GetCommit(lastCommitID)
require.NoError(t, err)
source, workflows, err := ListWorkflows(lastCommit)
require.NoError(t, err)
assert.Empty(t, source)
assert.Empty(t, workflows)
}
func TestActionsWorkflowsListWorkflowsIgnoresNonWorkflowFiles(t *testing.T) {
t.Cleanup(test.MockVariableValue(&setting.Git.HomePath, t.TempDir()))
require.NoError(t, git.InitSimple(t.Context()))
committer := git.Signature{
Email: "jane@example.com",
Name: "Jane",
When: time.Now(),
}
githubWorkflow := []byte(`
name: GitHub Workflow
on:
push:
jobs:
do-something:
runs-on: ubuntu-latest
steps:
- run: echo 'Hello GitHub'
`)
repoHome := t.TempDir()
require.NoError(t, os.MkdirAll(filepath.Join(repoHome, ".forgejo/workflows"), os.ModePerm))
require.NoError(t, os.WriteFile(filepath.Join(repoHome, ".forgejo/workflows", "README.md"), []byte("My project"), 0o644))
// Prepare a valid workflow in .github/workflows to verify that it is ignored because .forgejo/workflows is present.
require.NoError(t, os.MkdirAll(filepath.Join(repoHome, ".github/workflows"), os.ModePerm))
require.NoError(t, os.WriteFile(filepath.Join(repoHome, ".github/workflows", "github.yaml"), githubWorkflow, 0o644))
require.NoError(t, git.InitRepository(t.Context(), repoHome, false, git.Sha1ObjectFormat.Name()))
require.NoError(t, git.AddChanges(repoHome, true))
require.NoError(t, git.CommitChanges(repoHome, git.CommitChangesOptions{Message: "Import", Committer: &committer}))
gitRepo, err := git.OpenRepository(t.Context(), repoHome)
require.NoError(t, err)
defer gitRepo.Close()
headBranch, err := gitRepo.GetHEADBranch()
require.NoError(t, err)
lastCommitID, err := gitRepo.GetBranchCommitID(headBranch.Name)
require.NoError(t, err)
lastCommit, err := gitRepo.GetCommit(lastCommitID)
require.NoError(t, err)
source, workflows, err := ListWorkflows(lastCommit)
require.NoError(t, err)
assert.Equal(t, ".forgejo/workflows", source)
assert.Empty(t, workflows)
}
func TestActionsWorkflowsListWorkflowsReturnsForgejoWorkflowsOnly(t *testing.T) {
t.Cleanup(test.MockVariableValue(&setting.Git.HomePath, t.TempDir()))
require.NoError(t, git.InitSimple(t.Context()))
committer := git.Signature{
Email: "jane@example.com",
Name: "Jane",
When: time.Now(),
}
forgejoWorkflow := []byte(`
name: Forgejo Workflow
on:
push:
jobs:
do-something:
runs-on: ubuntu-latest
steps:
- run: echo 'Hello Forgejo'
`)
githubWorkflow := []byte(`
name: GitHub Workflow
on:
push:
jobs:
do-something:
runs-on: ubuntu-latest
steps:
- run: echo 'Hello GitHub'
`)
repoHome := t.TempDir()
require.NoError(t, os.MkdirAll(filepath.Join(repoHome, ".forgejo/workflows"), os.ModePerm))
require.NoError(t, os.WriteFile(filepath.Join(repoHome, ".forgejo/workflows", "forgejo.yaml"), forgejoWorkflow, 0o644))
require.NoError(t, os.MkdirAll(filepath.Join(repoHome, ".github/workflows"), os.ModePerm))
require.NoError(t, os.WriteFile(filepath.Join(repoHome, ".github/workflows", "github.yaml"), githubWorkflow, 0o644))
require.NoError(t, git.InitRepository(t.Context(), repoHome, false, git.Sha1ObjectFormat.Name()))
require.NoError(t, git.AddChanges(repoHome, true))
require.NoError(t, git.CommitChanges(repoHome, git.CommitChangesOptions{Message: "Import", Committer: &committer}))
gitRepo, err := git.OpenRepository(t.Context(), repoHome)
require.NoError(t, err)
defer gitRepo.Close()
headBranch, err := gitRepo.GetHEADBranch()
require.NoError(t, err)
lastCommitID, err := gitRepo.GetBranchCommitID(headBranch.Name)
require.NoError(t, err)
lastCommit, err := gitRepo.GetCommit(lastCommitID)
require.NoError(t, err)
source, workflows, err := ListWorkflows(lastCommit)
require.NoError(t, err)
assert.Len(t, workflows, 1)
assert.Equal(t, ".forgejo/workflows", source)
assert.Equal(t, "forgejo.yaml", workflows[0].Name())
}
func TestActionsWorkflowsListWorkflowsReturnsGitHubWorkflowsIfForgejoWorkflowsAbsent(t *testing.T) {
t.Cleanup(test.MockVariableValue(&setting.Git.HomePath, t.TempDir()))
require.NoError(t, git.InitSimple(t.Context()))
committer := git.Signature{
Email: "jane@example.com",
Name: "Jane",
When: time.Now(),
}
buildWorkflow := []byte(`
name: Build
on:
push:
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo 'We are building'
`)
testWorkflow := []byte(`
name: Test
on:
push:
jobs:
test:
runs-on: ubuntu-latest
steps:
- run: echo 'We are testing'
`)
repoHome := t.TempDir()
require.NoError(t, os.MkdirAll(filepath.Join(repoHome, ".github/workflows"), os.ModePerm))
require.NoError(t, os.WriteFile(filepath.Join(repoHome, ".github/workflows", "build.yaml"), buildWorkflow, 0o644))
require.NoError(t, os.WriteFile(filepath.Join(repoHome, ".github/workflows", "test.yml"), testWorkflow, 0o644))
require.NoError(t, git.InitRepository(t.Context(), repoHome, false, git.Sha1ObjectFormat.Name()))
require.NoError(t, git.AddChanges(repoHome, true))
require.NoError(t, git.CommitChanges(repoHome, git.CommitChangesOptions{Message: "Import", Committer: &committer}))
gitRepo, err := git.OpenRepository(t.Context(), repoHome)
require.NoError(t, err)
defer gitRepo.Close()
headBranch, err := gitRepo.GetHEADBranch()
require.NoError(t, err)
lastCommitID, err := gitRepo.GetBranchCommitID(headBranch.Name)
require.NoError(t, err)
lastCommit, err := gitRepo.GetCommit(lastCommitID)
require.NoError(t, err)
source, workflows, err := ListWorkflows(lastCommit)
require.NoError(t, err)
assert.Len(t, workflows, 2)
assert.Equal(t, ".github/workflows", source)
assert.Equal(t, "build.yaml", workflows[0].Name())
assert.Equal(t, "test.yml", workflows[1].Name())
}