Gitea actions - workflow in a non-main branch is not executed

[ruslan-mogilevskiy]

Description

Step to repro:

• create the .gitea/workflows/test.yml workflow with any job step and commit it into the main branch
• create an other branch feature/test-wf from the main and add or change job steps to the .gitea/workflows/test.yml in that branch
• in gitea UI, trigger the workflow manually (with on: workflow_dispatch) and choose the feature/test-wf branch in the shown popup.
  Note: you need at least 1.23.0-rc0 to run the workflow from Gitea UI.

Expected: the changed test.yml from the feature/test-wf branch is executed
Reality: .gitea/workflows/test.yml from the main branch is executed

Github correctly executes the triggered workflow from the selected branch but Gitea seems not and I didn't find the description of its behaviour in this case.

Gitea Version

1.23-rc0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Self-hosted in a host

Database

PostgreSQL

[changchaishi]

AFAIK Gitea's behavior is the same as Github's. The actions will always take the content (commands) from the main branch and execute them on behalf of your selected branch. It does not mean to use the chosen branch's commands but its environment.

[delvh]

IIRC, that's intended behavior for security reasons:
Otherwise, a malicious actor can simply log all secrets without you knowing, simply by changing an existing workflow on another branch, running the workflow, and deleting the branch again.
You don't want that to happen, so we cannot use your own changes to the workflow to execute the workflow.

[ChristopherHX]

GitHub only requires that the default branch defined workflow with the same path has a on workflow_dispatch trigger as well to use the workflow of the desired branch. (while this bit me as well, it's not as restrictive Giteas behavior described by the OP, I have not yet used this feature myself )

(this is a special case of manually triggered workflows on GitHub Actions)

Otherwise, a malicious actor can simply log all secrets without you knowing, simply by changing an existing workflow on another branch, running the workflow, and deleting the branch again.

You can do this already, just put on: push as a user with write access.

GitHub uses Deployment Environment Secrets for this kind of isolation (AFAIK, gitea does not implement them)

It does not mean to use the chosen branch's commands but its environment.

GitHub Actions actually always uses the workflow of its environment, so this is Gitea specific.

The following is GitHub specific, some might align with Gitea

• workflow_dispatch (users with write access / uses branch selected)
• pull_request (users with and without write access, uses PR branch and workflow (incl. fork), conditionally no secrets)
• pull_request_target (users with and without write access, uses target branch and workflow, has always secrets)
• push uses pushed branch for both env and workflow

[ChristopherHX]

Are there gitea code examples to refresh a view from backend after changing a branch combobox?

The backend logic would be easy to change for me, but making a static ssr template change on form change not.

GitHub sends new html fragments when doing this

EDIT Resolved, contribution guidelines / html docs, e.g. hx-get="/.../dispatchinputs" and so on with target dispatch inputs html fragment

[ruslan-mogilevskiy]

@changchaishi, in github, it is not working like you described. When you trigger a WF that has workflow_dispatch trigger inside, GH executes the WF file (possibly edited) from the selected branch (the main branch is needed only to declare your WF file). With this approach, you can edit your WF many times to finish your work and make a single squash commit into the master once finished.
Currently, to develop a WF in Gitea, I need to make dozens of commits right into the master and test them until I get what I need. This drastically pollutes the commit history.

@delvh, when a malicious actor has write access to your repo to push changes into your branches, the leakage of secrets becomes less critical.

[ChristopherHX]

I have finished a Proof of Concept patch, please test.

It was important for me to allow providing the inputs of the non default branch via the form like on GitHub

[ruslan-mogilevskiy]

@ChristopherHX , thanks for a quick PR and fix.

[ChristopherHX]

quick PR and fix

This could take until 1.24.0 for you to see this change.

main nightly (and gitea:nightly) has this change at the moment for testing purposes (you cannot downgrade to stable without restoring a backup once upgraded): https://dl.gitea.com/gitea/main-nightly/