I tried to create an action to check WIP status by watching PR title/label changes, but my implementation generates duplicate checks on every pull_request event.
Is there any way to avoid duplicate checks?
I tried to create an action to check WIP status by watching PR title/label changes, but my implementation generates duplicate checks on every pull_request event.
Is there any way to avoid duplicate checks?
Can you provide your workflow description? That will help understand what the triggers should be executing.
My implementation simply checks the PR title and label changes on pull_request event, then return exit code if these changes contain âWIPâ string.
Hereâs my workflow file:
name: WIP
on:
pull_request:
types: [labeled,unlabeled,opened,edited,reopened,synchronize]
jobs:
check:
runs-on: ubuntu-latest
steps:
- name: WIP
uses: mjhd-devlion/wip-kun-action@master
with:
token: ${{ secrets.GITHUB_TOKEN }}
owner: mjhd-devlion
repo: wip-kun-action
label: 'work-in-progress'
title: 'WIP: '
commits: 'wip,fixup!'
Looks like my previous comment somehow disappeared.
I have the same issue where duplicate checks are generated. This becomes a big issue when using âRequire status checks to pass before mergingâ on an action where this can happen. Letâs say you have an action which is triggered by the following:
on:
pull\_request:
types: [opened, reopened, edited, closed]
The action that is run validates the title of a Pull Request. When first opening the Pull Request the action is fired on the âopenedâ event and then fails that action because the title was wrong. The user now edits the Pull Request title and the action is rerun but this time with the âeditedâ event. This time the title was correct and the action succeeds. We now have two status checks on that Pull Request. One failed and one succeeded.
Since they are not grouped together itâs now impossible to merge this PR due to the âRequire status checks to pass before mergingâ check still seeing the check that was trigged on âopenedâ as failed.
I think that these checks should be grouped by the actual job that is selected under âRequire status checks to pass before mergingâ and use the latest ran to set the check as successful or not.
Iâm having the same issue.
I was able to work around it by writing my own action and having it send status checks through the API, then making that status check required - but not the actions themselves. This way the actions always succeed - but there will only ever be one status check that matters (gets overwritten every time title changes, for instance).
It seems like there should be a better way though. Either we should be able to de-clutter the âchecksâ to hide actions that are duplicated, or wonât fail - or there should be a way of grouping them all under a single âcheckâ in the interface obviating the need for and explicit status check call.
This is a good hack to get around the ârequired to be passingâ issue, but the underlying issue of multiple checks and check clutter is still there. I think the question is why arenât these being grouped? If one just does on: pull_request, Iâm faily sure the open, synchronize, reopen event types are being grouped.
Hi Chris,Â
We are also experiencing a similar problem and it seems like this could be a solution to us, but I am not quiet sure how you implemented it, would you explain?
How does you action look like and how does your workflow uses it?
Thanks
I am also seeing a similar problem⊠Has anyone been able to find out if this is intended behavior or discovered a work around?
I have managed to implement something that works for me (I suspect it is similar to what @christopherscott mentioned in his post).
I have removed all failures from my action, and added review status checks to dictate whether or not the action has been a success.
For example:
if (hasPassed) {
client.pulls.createReview({
owner: pullRequest.owner,
repo: pullRequest.repo,
pull_number: pullRequest.number,
body: 'Changes Requested',
event: 'REQUEST_CHANGES'
});
} else {
client.pulls.createReview({
owner: pullRequest.owner,
repo: pullRequest.repo,
pull_number: pullRequest.number,
body: 'Approved',
event: 'APPROVE'
});
}
The event options available are:
This then creates a comment on the pull request with either an approval or a request for changes and the action can run and duplicate as many times as it needs:
I hope this is useful and helps.
Sam
Iâm seeing the same behavior. My workflow is triggered by
on:
pull_request:
types: [opened, synchronize, reopened, edited]
 and validates the PR title and body. If the workflow fails initially (which in turn creates a failed Check in the UI), I update the title and/or body to fix the issue, but a new check gets created every time I edit the PR and the original failed workflow/check is not removed or updated.Â
Any fixes for this one? I am having the same issue with using âpull_requestâ where we get many duplicate checks.
Created a new github action that uses the approve flow to fix this!
https://github.com/cschubiner/action-pr-title
Usage
name: PR Title
on:
pull_request:
types: [review_requested, edited, opened, assigned]
jobs:
pr_title:
runs-on: ubuntu-latest
steps:
- uses: cschubiner/action-pr-title@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
allowed_prefixes: 'BREAKING CHANGE:,chore:,docs:,feat:,fix:,perf:,refactor:,style:,test:'
prefix_case_sensitive: true
min_length: 7 # Min length of the title
max_length: 200 # Max length of the title
Is this expected behaviour when specifying multiple types?
Seems a strange approach if it is the expected behaviour.
Or is it logged anywhere as an issue?
Iâm hitting this same issue. Hereâs my workflow:
name: Lint front matter
on:
pull_request:
types: [opened, synchronize, reopened, labeled, unlabeled]
paths:
- '**.md'
jobs:
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v1
- name: Setup node
uses: actions/setup-node@v1
with:
node-version: '12.x'
- name: Cache node_modules
uses: actions/cache@v1
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- name: Install
run: npm ci
- name: Git diff
id: git_diff
uses: futuratrepadeira/changed-files@v3.0.1
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
- name: Lint yaml front matter
id: lint_front_matter
uses: ./.github/actions/lint-front-matter
with:
added: ${{ steps.git_diff.outputs.files_created }}
modified: ${{ steps.git_diff.outputs.files_updated }}
# Only run the linter if the previous step indicated that files were
# added or modified in the pull request.
if: steps.git_diff.outputs.files_created || steps.git_diff.outputs.files_updated
- name: Find comment
id: find_comment
uses: ./.github/actions/find-comment
with:
token: ${{ secrets.GITHUB_TOKEN }}
if: always() && steps.lint_front_matter.outputs.message
- name: Create or update comment
uses: peter-evans/create-or-update-comment@v1.1.0
with:
token: ${{ secrets.GITHUB_TOKEN }}
issue-number: ${{ github.event.number }}
comment-id: ${{ steps.find_comment.outputs.comment-id }}
body: |
${{ steps.lint_front_matter.outputs.message }}
edit-mode: replace
if: always() && steps.lint_front_matter.outputs.message
What this does is lint the yaml frontmatter of any changed markdown files, then it posts a comment saying whether it passed or failed. If it failed, a developer can add a label to the pull request which will rerun the workflow and tell it to skip the previously failing tests.
Adding the labeled and unlabeled types seemed to cause the problem. It seems like perhaps opened/synchronize/reopened are considered one kind of check, and labeled/unlabled are treated as a separate check.
**EDIT**
I just tried removing the types array and relying on the default behavior of pull_request. According to the docs, this should run the workflow on opened, synchronize, and reopened. What I found was if you close and reopen the pull request it will create a duplicate check. However, if you push a new commit (synchronize) it will clear all status checks and only show one check. This seems like a bug?
Had this problem too when using the edited
trigger. Iâve implemented a workaround for now in my linter v.1.1.0
Basically for now:
* When the check fails, the bot requests changes and comments with the failure message
* If the check succeeds in the future, the bot will dismiss its review (intentionally donât âapproveâ to allow for code review workflows)
Would be nice if there were a good way to do this as OP mentions though.
I spoke with GitHub support and it looks like theyâve since fixed this issue. I was able to confirm today that itâs no longer producing duplicate checks for me.
This still seems to be an issue, a duplicate step that always fails.Â
https://github.com/square/workflow/pull/1136/checks?check_run_id=650433831
I experience duplicate checks on unlabeled event when more then one label is added/removed. This prevents me to use labeling to manage some further pipelines.
I published âskip-duplicate-actionsâ to solve this problem: https://github.com/marketplace/actions/skip-duplicate-actions
You could give it a try if this is still an issue.
Something like the following fixed it for me (tags-ignore and branch-ignore specifically):
on:
workflow_dispatch: # * Treated like a `push` event with custom refs
push:
tags-ignore: ['**']
branches-ignore: ['dependabot/**', 'snyk-*', 'no-ci/**']
pull_request:
types: [opened, synchronize]
branches: [main, canary]