GitHub Community
-
|
Hello! I’ve noticed some recent repos I’ve setup with GitHub Actions seem to be duplicating work on pull requests and running/logging the tests for both the push and pull_request actions. What’s weird though is I’ve scanned through a few other repos (that aren’t mine) that seem to be configured in a similar way that do not have this issue? You can see an example of it here and in the following screenshot. Definitely possible I goofed my workflow config as well. 😅 |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 4 replies
-
|
This is a correct behavior, not an issue. In the Checks of a PR, it will list all the jobs from the workflows run on the push event and the pull_request event based on the latest commit in the HEAD branch (source branch of the PR). Currently, we have no methods to only list the the jobs run on the pull_request event. Because you configure your “Node CI” workflow runs on both push and pull_request , when you push commit the workflow will be triggered, and when the PR is Open , this workflow also will be triggered by the pull_request. So on the checks list of your PR, it will list two similar checks triggered by different events ( push and pull_request ). |
Beta Was this translation helpful? Give feedback.
-
|
Is my previous helpful to your? If you have any other question about this ticket, feel free to tell us. |
Beta Was this translation helpful? Give feedback.
-
|
Ah — so maybe what I’m after is just [push]? That would continue logging the latest check of a push of that branch in the pull request? I think that’s all I truly care about, I currently have nothing special expected to happen on a pull. |
Beta Was this translation helpful? Give feedback.
-
|
To avoid the duplicate checks being generated on the same PR, you can try to just set pull_request event or push event for the workflow. Or set branches filter on them. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for clarifying! This makes sense now. I’ll accept your original response as the answer — I think it summarizes it well. |
Beta Was this translation helpful? Give feedback.
-
|
@BrightRan just setting |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I think I found the best solution: on:
push:
branches:
- main
- release-*
pull_request:This one will trigger |
Beta Was this translation helpful? Give feedback.
-
|
That's almost right. But what I'm after is to trigger on push to any branch (even the non-main ones that I'm developing on), but also on pull requests that are potentially open by other people (from forks). How to do that without duplicating jobs? |
Beta Was this translation helpful? Give feedback.
-
|
I've been working on this today. My solution when both push and pull_request can trigger the workflow is to use this (large) expression to enable/disable the execution of each job: The first condition in the OR expression avoids the duplicates (disables PRs coming from the repo), and the second one allows PRs when coming from forked projects or dependabot updates. |
Beta Was this translation helpful? Give feedback.
-
|
@javiertuya why the dependabot check? In my case my exact problem is about dependabot PRs, because they trigger both the push and the PR event. So I do want to trigger on dependabot pushes and fork PRs, but not dependabot PRs (to support force pushes) |
Beta Was this translation helpful? Give feedback.
-
|
@joffrey-bion The reason is that in my typical configuration of workflow triggers, I ignore push events for dependabot updates: This trigger configuration removes the dependabot duplicates when an update is created. Works fine in my case. Is not exactly your scenario, but I hope helps you. |
Beta Was this translation helpful? Give feedback.
-
|
It's an issue for me, what I'm trying to achieve is a single status check that:
If I set the job required for the pull request the developers will never be able to merge their PRs because of two duplicate checks instead of one check I also tried Current workflow: name: Protected Topics Check
on:
pull_request_review:
types: [ submitted ]
branches:
- master
paths:
- 'clusters/*/kustomize/kafka-resources/users/*.yaml'
pull_request:
branches:
- master
paths:
- 'clusters/*/kustomize/kafka-resources/users/*.yaml'
concurrency:
group: protected-topics-${{ inputs.pr_number }}
cancel-in-progress: true
jobs:
protected-topics:
# check kafka topics@BrightRan can you please help how can we use multiple triggers for a single status check ? |
Beta Was this translation helpful? Give feedback.
@rdmurphy ,
This is a correct behavior, not an issue. In the Checks of a PR, it will list all the jobs from the workflows run on the push event and the pull_request event based on the latest commit in the HEAD branch (source branch of the PR). Currently, we have no methods to only list the the jobs run on the pull_request event.
Because you configure your “Node CI” workflow runs on both push and pull_request , when you push commit the workflow will be triggered, and when the PR is Open , this workflow also will be triggered by the pull_request. So on the checks list of your PR, it will list two similar checks triggered by different events ( push and pull_request ).