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

[efb4f5ff-1298-471a-8973-3d47447115dc]

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]

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]

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

• Improve styling of premiere date box FreeTubeApp/FreeTube#2611
• Implementing showOpenDialog's web callback FreeTubeApp/FreeTube#2608
• Compress and lazy load locales FreeTubeApp/FreeTube#2603
• Making pack:web work by adding polyfill FreeTubeApp/FreeTube#2678

File locations:

• https://github.com/FreeTubeApp/FreeTube/blob/development/.github/workflows/conflicts.yml
• https://github.com/FreeTubeApp/FreeTube/blob/development/.github/workflows/dummy-conflicts.yml

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]

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]

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

[efb4f5ff-1298-471a-8973-3d47447115dc]

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]

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?