Enable comment delete function

[moneymikeMD]

github-pr-comment-step/pr-comment-plugin.yml

Line 96 in 0f076e4

# - GITHUB_DELETE_COMMENT_REGEX=staging

Was wondering why this line was commented out or not made available in a future version? This would be useful to reduce the automated chatter in our PRs that come from pushing a new commit and the step commenting with a new preview app URL, rendering the old comment useless (that's our usecase).

[kostis-codefresh]

Hello.

There are two considerations for this option.

First of all it is a regex so it is very easy to mishandle. For example if you post a comment "your staging environment is ready at http://example.com" and simply put "staging" in the regex it will delete ALL comments with that word even if they are unrelated. If the PR has existing comments like "Please check the staging database before merging this PR", that comment will be deleted as well. So as a useful feature it is very easy to abuse and needs careful consideration on how to use it. Right now, the plugin works in a reliable manner because you cannot misuse it (it never deletes previous comments by design)

The second reason is that while I understand your use case (cleaning up old comments), not all organizations work like this. In your case the preview URL is always a new one (correct me please if I am wrong) and so all the old comments are indeed invalid. But in several other cases the preview URL is the same and customers like to see old comments because they function as a release history and they can see exactly when the single staging environment was redeployed.

That being said, the plugin is fully open source. You can clone it, modify it as you want and re-release with your own namespace (i.e. moneymikeMD/github-pr-comment-step) and have it work according to your needs.

I thought about enabling what you want in a later version of the plugin, but this might break the workflows of existing customers and deleting PR comments by mistake is not something that should be taken lightly.

Let me know what you think.

[moneymikeMD]

These are valid concerns, @kostis-codefresh . While forking the repo is an option, I thought adding the option back in to the "primary" version is a better way to go (we all point to this repo). Your second reason is spot on for our usecase: we generate ephemeral URLs for preview environments and for PRs where engineers are pushing multiple commits, the overwhelming majority of comments are the preview environment link updates.

[kostis-codefresh]

@moneymikeMD I see.

Ok do you want to submit a PR on this primary step then? If you change the version of the plugin to 2.0.0 (or something similar) I will gladly accept the change. And then people can choose 1.0.0 or 2.0.0 according to their needs.

I can work on this myself as well, but my backlog is pretty full at the moment, so it will be some time before I reach this (if you need it ASAP)

Let me know how you want to proceed.