search

eps1lon / actions-label-merge-conflict

GitHub action that adds a label once a PR has merge conflicts
46 stars 16 forks source link

add label back when conflicts are resolved if the label was removed #88

Open efb4f5ff-1298-471a-8973-3d47447115dc opened 2 years ago

efb4f5ff-1298-471a-8973-3d47447115dc commented 2 years ago

When removeOnDirtyLabel removes the label it doesnt add the label back when the conflicts are resolved. It would be nice for the workkflow to do that also.

If the label wasn't present when the conflicts occurred the workflow doesn't have to apply a label.

eps1lon commented 2 years ago

When removeOnDirtyLabel removes the label it doesnt add the label back when the conflicts are resolved.

You're saying it doesn't add removeOnDirtyLabel when conflicts are resolved? This sounds like a bug to me. Please include a PR and ideally GH workflow logs where this didn't happen

efb4f5ff-1298-471a-8973-3d47447115dc commented 2 years ago

When removeOnDirtyLabel removes the label it doesnt add the label back when the conflicts are resolved.

You're saying it doesn't add removeOnDirtyLabel when conflicts are resolved?

That is correct

This sounds like a bug to me. Please include a PR and ideally GH workflow logs where this didn't happen

File locations:

The dummy workflow ensures that the workflow also works on pr opened on forks. If u dont include this workflow PRs from forks get a github API error.

eps1lon commented 2 years ago

Ah now I remember. I think this was intended since the label that's removed could be something like "ready to merge". And rebase after review kind of invalidates that. But that depends on the semantics of the labels so an option to add the removeOnDirtyLabel back does make more sense 👍🏻

Thanks for adding the PRs. Made it clearer why you'd want that behavior.

Feel free to send a PR adding such an option.

efb4f5ff-1298-471a-8973-3d47447115dc commented 2 years ago

Unfortunately i have no experience with GH actions. So cant help u with that :(

efb4f5ff-1298-471a-8973-3d47447115dc commented 2 years ago

Just a thought. For our usecase/workflow it make totally sense but maybe for others not.

Only add the label back when it was removed.

ferdnyc commented 1 year ago

Is it actually possible for the action to add back a label "only if it was removed"? Where would that state be kept?

I was initially thinking that, to get behavior that's flexible enough to handle everyone's use cases, there would need to be cleanLabel and removeOnCleanLabel options, in addition to the existing dirtyLabel and removeOnDirtyLabel.

But even that doesn't cover the case where the action should remove and restore externally-created labels, but only the ones it's previously placed/removed. That would require the action keeping a history of its own changes somewhere, which (correct me if I'm wrong) I don't think it currently does?