feat: do not skip merge group

[wahtique]

• add merge_group as workflow trigger
• add merge_group to default value sfor do-not-skip triggers : else, worfklow will be skipped when the PR is added to a merge queue since it just ran before

[koppor]

There are some checks failing. If using this PR ( `uses: wahtique/skip-duplicate-actions@2e9b67bfb35498c7753464fb193af7233a41b164``), I get

Error: Elements in 'do_not_skip' must be one of "pull_request", "push", "workflow_dispatch", "schedule", "release"

[fkirc]

Thank you for submitting the PR!

[fkirc]

I cannot merge it without the compiled JS, we need the compiled JS updated for this to work

[fkirc]

Merged, thank you for updating the JS!

[paescuj]

Thanks for the PR @wahtique!

Sorry for my late & post-merge comment, but

• add merge_group to default value sfor do-not-skip triggers : else, worfklow will be skipped when the PR is added to a merge queue since it just ran before

doesn't it make sense that it is skipped? 😄

[paescuj]

@fkirc WDYT about this https://github.com/fkirc/skip-duplicate-actions/pull/329#issuecomment-1753304578? If the tree hash is the same in merge group it makes sense to skip it IMO? However, I totally agree with the addition of merge_group to do_not_skip 👍

[wahtique]

In response to https://github.com/fkirc/skip-duplicate-actions/pull/329#issuecomment-1753304578

That was some time ago but use case was :

• open a PR with some checks in a workflow
• checks pass
• review pass
• PR added to merge queue
• ... and nothing happens the check is skipped
• merge queue is never merged

Possible fixes would be

• run no check on either PR or merge queue => big nope
• update this action to have special behaviour for the merge queue => sorry that's above my skills 😅
• write 2 workflows with the same checks, one for PRs and one for merge queue which can be done buuuut...I dunno I don't like it, it does not feel DRY even if we mutualise the checks definitions and only do workflow calls from our duplicated workflows
• the solution implemented in this PR : run it twice, PR is checked, merge queue code ( which can contain more than one PR ) is checked and everyone except my company's finances is happy

[fkirc]

@fkirc WDYT about this #329 (comment)? If the tree hash is the same in merge group it makes sense to skip it IMO? However, I totally agree with the addition of merge_group to do_not_skip 👍

I would agree to skip if a tree hash is in the same merge group, but I do not know how to implement it at the moment. So right now I believe the „do_not_skip“ is the easiest workaround.

[fkirc]

@fkirc WDYT about this #329 (comment)? If the tree hash is the same in merge group it makes sense to skip it IMO? However, I totally agree with the addition of merge_group to do_not_skip 👍

I would agree to skip if a tree hash is in the same merge group, but I do not know how to implement it at the moment. So right now I believe the „do_not_skip“ is the easiest workaround.