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

[skt-mmisuth]

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

[Zettat123]

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?

[skt-mmisuth]

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.

[dante11235]

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

[skt-mmisuth]

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?

[Zettat123]

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.