feat: Add merge conflict labeler workflow

[Gauvino]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Before merging the PR you have to manually add the label merge conflict

Put a label merge conflict on PR with merge conflict and comment also to say to the maintainer that PR as merge conflict.

Would be simpler to review PR and also gain time cause when merge conflict is detected the maintainer can solve it so you don't have to say to him manually to solve the merge conflict.

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

[CommanderStorm]

I don't think this would add value for my workflow.

Merging PRs is not much of the work required unless there have been other competing PRs such as in the case in this example:

• Timeline-based incident system #1253

In the case where it is significant work, that would have to be done by the PR-author though for scalabiltiy... => That would need a comment anyway..

[Gauvino]

No problem then, if you don't think you need this, just wanted to help the project, because it would certainly make you gain time by not having to say everytime there is a conflict on a PR to solve it and also do some triage.

[CommanderStorm]

@Zaid-maker @Saibamen
Would this Action help your workflow?
(being curious: what is your workflow?)

[Zaid-maker]

@Zaid-maker @Saibamen
Would this Action help your workflow?
(being curious: what is your workflow?)

Yes, I tested it on my repo works really well let's say I have a benchmark tool which benchmark different frameworks and it's all automated through actions, now if someone wants to add a feature they had to run the start command which generates benchmark result and after that they made a PR and when I try to review it says that this PR commits has merge conflict with main branch.... So I tested this action against that repo and surprisingly it works great. If u want I will share more on that <3

[Gauvino]

If any change need to be made, I will for sure help the project and if you have any other request on adding new workflow I could look at it

[Zaid-maker]

If any change need to be made, I will for sure help the project and if you have any other request on adding new workflow I could look at it

Made it send a message aswell mentioning author(s) of PR that "please resolve merge conflict...." like that

[Gauvino]

If any change need to be made, I will for sure help the project and if you have any other request on adding new workflow I could look at it

Made it send a message aswell mentioning author(s) of PR that "please resolve merge conflict...." like that

No problem will hade his in the night cause right now I can't sorry

[Saibamen]

This is helpful even for small teams and repos.

[Zaid-maker]

Good to go!

[Gauvino]

You also want a message when conflict have been resolved ?

[CommanderStorm]

I'd like there to not be a comment.
I am thinking about how frustrated I would be if this comment would come up for the second/third/fourth time (without there being a review)

=> I am kind of scared that this would be driving away people..

what do others think (and why)?

[Zaid-maker]

You also want a message when conflict have been resolved ?

Yes

[Gauvino]

I'd like there to not be a comment.

I am thinking about how frustrated I would be if this comment would come up for the second/third/fourth time.

=> I am kind of scared that this would be driving away people..

what do others think (and why)?

I think the same as you to be honest, it would continuously be spamming notifications, I think the best would be to only add the merge conflict message not the one when it's been resolved

Edit: For me the main point of this workflow is to notify the maintainer of the PR so resolved the conflict

[Zaid-maker]

Maybe just add the label 🔖 and get the job done 💁

Also there would be very rare chance we get a PR (expect old pending PR's) which has merge conflict.

[Gauvino]

Maybe just add the label 🔖 and get the job done 💁

So just the labeling and no message at all, I liked too like this, would not be a mess in notifications

[Zaid-maker]

So just the labeling and no message at all, I liked too like this, would not be a mess in notifications

Let's hear from @CommanderStorm first then we make decisions

[CommanderStorm]

Just adding a label is kind of pointless, right?

for contributors:
The only time a contributor would see it if they are viewing the PR on GitHub
=> would already see the "this PR has a merge" button.

for reviewers:
=> I would not know how to use this label. adding the new needs:work this PR needs work label seems like a better (more human) way..
=> Back to my original question: how would others use this label?

[Zaid-maker]

Just adding a label is kind of pointless, right?

I say only if we want to make the PR more clear and concise so no one panics

for contributors: The only time a contributor would see it if they are viewing the PR on GitHub => would already see the "this PR has a merge" button.

For that we should use the message thing to notify contributors.

for reviewers: => I would not know how to use this label. adding the new needs:work this PR needs work label seems like a better (more human) way.. => Back to my original question: how would others use this label?

It's automatic u don't have to manually add the label i guess, with this others will be more punctual that they had to resolve merge conflict and they will invest more time in the Feature (That's my POV)

.... and the end i would say others will be more active than before instead of losing there interest in the feature

[Saibamen]

Having a comment is important for pinging the PR author. Without it, he won't know if his PR is outdated!

[Saibamen]

Suggested change

	removeOnDirtyLabel: 'needs:resolve-merge-conflict'
	removeOnDirtyLabel: 'needs:resolve-merge-conflict'
	commentOnDirty: 'This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged.'

[CommanderStorm]

Without it, he won't know if his PR is outdated

And? Please see my comment from above why I think that that is not as bad as you think it is..

Merging PRs is not much of the work required unless there have been other competing PRs such as in the case in this example:

• Timeline-based incident system #1253

In the case where it is significant work, that would have to be done by the PR-author though for scalabiltiy...
=> That would need a comment anyway..

And my concern from the other comment:

I'd like there to not be a comment.
I am thinking about how frustrated I would be if this comment would come up for the second/third/fourth time (without there being a review)
=> I am kind of scared that this would be driving away people..

[Zaid-maker]

The label should be red