Sometimes multiple PR/PRMERGE tied workflows are run, despite paths and triggering conditions not overlapping/fullfiled #13483

New Issue

GiteaMirror · 2025-11-02T10:43:47-06:00

GiteaMirror commented

2025-11-02 10:43:47 -06:00

Originally created by @skt-mmisuth on GitHub (Sep 12, 2024).

Description

We are experiencing an issue where mutiple workflows fire unexpectedly. We observed act_runner logs a bit, but it seems that workflow dispatching is being handled in gitea server itself.

We need advice on how to approach this problem. We can provide sanitized logs if needed, but I would like to avoid that, due to sensitive nature of the repos being handled.

I am creating this issue in case other people are having similar problem.

Gitea Version

1.21.7

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Both of these workflows have paths sections mapping different parts of the monorepo, yet they are being triggered:

...
on: 
  push:
    branches: ['main']
    paths: 
      - '.gitea/workflows/...' # self referenting name to catch its own updates
      - 'terraform/**'
...

...
on: 
  push:
    branches: ['main']
    paths: 
      - '.gitea/workflows/...' # self referenting name to catch its own updates
      - 'ansible/**'
...

According to our understanting, only the workflow, that matches modified paths should be triggered, yet sometimes, multiple workflows fire ... how is that possible?

Are we misunderstading something?

Git Version

2.39.3

Operating System

OracleLinux 8.9

How are you running Gitea?

Gitea is being run as system level systemd service (official one provided by gitea project and installed using official documentation) running under "git-dedicated" user.

It was installed onto the node directly using official documentation.

Database

PostgreSQL

Originally created by @skt-mmisuth on GitHub (Sep 12, 2024). ### Description We are experiencing an issue where mutiple workflows fire unexpectedly. We observed `act_runner` logs a bit, but it seems that workflow dispatching is being handled in gitea server itself. We need advice on how to approach this problem. We can provide sanitized logs if needed, but I would like to avoid that, due to sensitive nature of the repos being handled. I am creating this issue in case other people are having similar problem. ### Gitea Version 1.21.7 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![image](https://github.com/user-attachments/assets/be191a8a-eb15-4636-a1a8-e8ded3ffb38e) Both of these workflows have paths sections mapping different parts of the monorepo, yet they are being triggered: ``` ... on: push: branches: ['main'] paths: - '.gitea/workflows/...' # self referenting name to catch its own updates - 'terraform/**' ... ``` ``` ... on: push: branches: ['main'] paths: - '.gitea/workflows/...' # self referenting name to catch its own updates - 'ansible/**' ... ``` According to our understanting, only the workflow, that matches modified paths should be triggered, yet sometimes, multiple workflows fire ... how is that possible? Are we misunderstading something? ### Git Version 2.39.3 ### Operating System OracleLinux 8.9 ### How are you running Gitea? Gitea is being run as system level systemd service (official one provided by gitea project and installed using official documentation) running under "git-dedicated" user. It was installed onto the node directly using official documentation. ### Database PostgreSQL

GiteaMirror added the topic/gitea-actions type/bug labels 2025-11-02 10:43:47 -06:00

GiteaMirror commented

2025-11-02 10:43:47 -06:00

@Zettat123 commented on GitHub (Sep 19, 2024):

From the screenshot, if I understand correctly, you may have pushed some changes in terraform/** to the main branch. In this case, only terraform-xxx.yaml should be triggered, but in fact ansible-xxx.yaml is also triggered.

However, I cannot reproduce this issue on my instance. If possible, could you provide some detailed steps to help us reproduce it?

@Zettat123 commented on GitHub (Sep 19, 2024): From the screenshot, if I understand correctly, you may have pushed some changes in `terraform/**` to the main branch. In this case, only `terraform-xxx.yaml` should be triggered, but in fact `ansible-xxx.yaml` is also triggered. However, I cannot reproduce this issue on my instance. If possible, could you provide some detailed steps to help us reproduce it?

GiteaMirror commented

2025-11-02 10:43:48 -06:00

@skt-mmisuth commented on GitHub (Sep 26, 2024):

Sorry, I haven't had time to report back on this because of $work.

The bug is very hard to trigger, and we don't really know what is actually causing it, but my colleague suggests it could have happened when pull request was cancelled and recreated anew, but on the same branch.

As I said, I've haven't the time to verify this theory, but I am still reporting here, if you, or anybody else, really, wants to try that.

I will try to find time to attempt to trigger it next week.

@skt-mmisuth commented on GitHub (Sep 26, 2024): Sorry, I haven't had time to report back on this because of $work. The bug is very hard to trigger, and we don't really know what is actually causing it, but my colleague suggests it could have happened when pull request was cancelled and recreated anew, but on the same branch. As I said, I've haven't the time to verify this theory, but I am still reporting here, if you, or anybody else, really, wants to try that. I will try to find time to attempt to trigger it next week.

GiteaMirror commented

2025-11-02 10:43:48 -06:00

@dante11235 commented on GitHub (Sep 30, 2024):

Hello, I was able to reproduce this issue and it happens in this situation.

You start to work, create your working branch "branch-feature". You develop what you need and it takes few hours. You only work with folder folder1/ . In the meantime, your colleague is doing a hotfix in the repo and creates "branch-fix". He is really fast and merges the his branch to main. He only operated on folder2/

There are 2 gitea workflows which monitor respective folders

workflow1:
paths:
- 'folder1/**'

workflow2:
paths:
- 'folder2/**'

You now push the branch "branch-feature" to upstream and create a merge request. Your gitea workflow now executes both workflow1 and workflow2 because, from gitea point of view, the change in your PR has difference between folder2 in main and in new branch.

Is this desired state? The issue with this is that if he has done "breaking change" in branch-fix, now my action for the workflow2 is failing. The fix for this is to update my branch with changes from main

@dante11235 commented on GitHub (Sep 30, 2024): Hello, I was able to reproduce this issue and it happens in this situation. You start to work, create your working branch "branch-feature". You develop what you need and it takes few hours. You only work with folder folder1/ . In the meantime, your colleague is doing a hotfix in the repo and creates "branch-fix". He is really fast and merges the his branch to main. He only operated on folder2/ There are 2 gitea workflows which monitor respective folders workflow1: paths: - 'folder1/**' workflow2: paths: - 'folder2/**' You now push the branch "branch-feature" to upstream and create a merge request. Your gitea workflow now executes both workflow1 and workflow2 because, from gitea point of view, the change in your PR has difference between folder2 in main and in new branch. Is this desired state? The issue with this is that if he has done "breaking change" in branch-fix, now my action for the workflow2 is failing. The fix for this is to update my branch with changes from main

GiteaMirror commented

2025-11-02 10:43:48 -06:00

@skt-mmisuth commented on GitHub (Oct 3, 2024):

Indeed, we had time to dbeug it further and it seems this caused by PEBKAC, or misunderstanding of how git and monorepos work.

Let's say we have a main branch and multiple people, with their own "private" branches commiting changes and merging their personal branches back to main through branch protection. As the work happens organically at any point any colleague might merge back to main, thus moving main "forward".

Now "private" work branches of all other colleagues are out of sync with main. To remediate this situation, I told them to merge main into their branches, as soon as they spot differences, because I considered "merge main to private" safest option.

Unfortunately, this merge commit then "pulls-in" changes on main, made by other colleagues, into the private branch of current colleague. This means, that commit stream on given branch "touches/references" even files, that the current colleague was not working on. But from the POV of gitea, now commit stream touches all the files changed in the meantime, and thus it fires all the workflows anyway, because merge commit matches even those other paths.

I was playing with this, and it seems that safest bet, for priovate branches is to use rebase on main, instead of merging it. Now the commit stream contains only commits made by given colleague, and gitea workflow matching then fires only on objects that the colleague touched.

For less experienced colleagues, we tried to use whole edit process through gitea webui, and it seems to work relatively fine, however when there is a conflict, gitea web ui doesn't present any conflict resolution solution.

So, I assume this is by design, right?

My second question regarding this behaviour is, that if we ensure that each branch is "private" for members, rebasing is proper strategy, right?

Are there any provisions in action workflows to somehow ignore the other parts of the monorepo paths?

I found exclude path specifiers in github workflows. So maybe excluding all paths in every workflow first and than only including specific paths would work around this issue - am I right in my reasoning?

@skt-mmisuth commented on GitHub (Oct 3, 2024): Indeed, we had time to dbeug it further and it seems this caused by PEBKAC, or misunderstanding of how git and monorepos work. Let's say we have a `main` branch and multiple people, with their own "private" branches commiting changes and merging their personal branches back to main through branch protection. As the work happens organically at any point any colleague might merge back to `main`, thus moving `main` "forward". Now "private" work branches of all other colleagues are out of sync with `main`. To remediate this situation, I told them to merge main into their branches, as soon as they spot differences, because I considered "merge main to private" safest option. Unfortunately, this merge commit then "pulls-in" changes on `main`, made by other colleagues, into the private branch of current colleague. This means, that commit stream on given branch "touches/references" even files, that the current colleague was not working on. But from the POV of gitea, now commit stream touches all the files changed in the meantime, and thus it fires all the workflows anyway, because merge commit matches even those other paths. I was playing with this, and it seems that safest bet, for priovate branches is to use `rebase` on main, instead of merging it. Now the commit stream contains only commits made by given colleague, and gitea workflow matching then fires only on objects that the colleague touched. For less experienced colleagues, we tried to use whole edit process through gitea webui, and it seems to work relatively fine, however when there is a conflict, gitea web ui doesn't present any conflict resolution solution. So, I assume this is by design, right? My second question regarding this behaviour is, that if we ensure that each branch is "private" for members, rebasing is proper strategy, right? Are there any provisions in action workflows to somehow ignore the other parts of the monorepo paths? I found exclude path specifiers in github workflows. So maybe excluding all paths in every workflow first and than only including specific paths would work around this issue - am I right in my reasoning?

GiteaMirror commented

2025-11-02 10:43:48 -06:00

@Zettat123 commented on GitHub (Oct 11, 2024):

You now push the branch "branch-feature" to upstream and create a merge request. Your gitea workflow now executes both workflow1 and workflow2

@dante11235 Thanks for your feedback. Do you mean that both "workflow1" and "workflow2" were executed after you pushed the "branch-feature" branch and before you updated the branch with changes from main? But I still cannot reproduce this issue. In my test, in this case, only "workflow1" was executed.

@Zettat123 commented on GitHub (Oct 11, 2024): > You now push the branch "branch-feature" to upstream and create a merge request. Your gitea workflow now executes both workflow1 and workflow2 @dante11235 Thanks for your feedback. Do you mean that both "workflow1" and "workflow2" were executed after you pushed the "branch-feature" branch and before you updated the branch with changes from main? But I still cannot reproduce this issue. In my test, in this case, only "workflow1" was executed.

GiteaMirror commented

2025-11-02 10:43:48 -06:00

@lunny commented on GitHub (Oct 26, 2024):

Please create a test repo on https://demo.gitea.com

@lunny commented on GitHub (Oct 26, 2024): Please create a test repo on https://demo.gitea.com

GiteaMirror commented

2025-11-02 10:43:49 -06:00

@skt-mmisuth commented on GitHub (Jul 18, 2025):

So for us, the solution is to always rebase feat/* work branch by people who are working on it, onto our primary main branch, before the gitea assisted (branch protection) merge.

Otherwise, if main branch is merged onto feat/*, feat/* will naturally pick commits from other people from main that happened. Thus when workflow engine is calculating changed files, it seems to also includes commits from other people who changed files somewhere on main. This then triggers worflows that were already merged onto main and already applied by CI/CD previously.

For us it seems that easiest way to solve this is to always rebase feat work onto latest main.

Is there any other way to solve this?

@skt-mmisuth commented on GitHub (Jul 18, 2025): So for us, the solution is to always rebase `feat/*` work branch by people who are working on it, onto our primary `main` branch, before the gitea assisted (branch protection) merge. Otherwise, if `main` branch is merged onto `feat/*`, `feat/*` will naturally pick commits from other people from `main` that happened. Thus when workflow engine is calculating changed files, it seems to also includes commits from other people who changed files somewhere on main. This then triggers worflows that were already merged onto main and already applied by CI/CD previously. For us it seems that easiest way to solve this is to always rebase feat work onto latest main. Is there any other way to solve this?

GiteaMirror commented

2025-11-02 10:43:49 -06:00

@skt-mmisuth commented on GitHub (Sep 17, 2025):

Just confirming with somebody more experienced whether rebase workflow, is correct way to go?

@skt-mmisuth commented on GitHub (Sep 17, 2025): Just confirming with somebody more experienced whether rebase workflow, is correct way to go?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13483