Create a BucketPPRPullRequestCommentCreatedFilter about bitbucket-push-and-pull-request-plugin

[macghriogair]

I think I get the point and it would be feasible. The question is more whether we want to add another event to the plugin and maintain it, @cdelmonte-zg ? Anyway, it would probably be a low prio since there are still alternatives to retrigger a build and it sounds like an edge case.
Don't get me wrong, I like the idea behind it of executing a build by human instruction ( in the manner of "Computer, re-run the build" 😉).

Btw (for inspiration), there is a GitHub plugin doing just this: https://github.com/jenkinsci/github-pr-comment-build-plugin/blob/master/README.md

[cdelmonte-zg]

Supported starting from v2.3.3

[macghriogair]

Hey @ysabri ,
thank you for opening an issue.

Why don't you use tags instead of comments? Or could you provide more background information about your use case?
I don't see this feature to be a general advantage for the broader audience.

[ysabri]

Hey @macghriogair,

I am confused about what tags you are referring to. Do you mean Git tags or are there Bitbucket PR tags I'm not aware of.

My use case is for already open PRs that the user wants to run the Jenkins build/s for again.
It happens sometimes for us where a Jenkins build fails due to some configuration problem outside of the source code.
After those problems are fixed, we are forced to either push an empty change commit or close then open the PRs to run the builds on them again.
It would be really nice if we can comment on the PR with something like "build" that would trigger the build/s again.

[macghriogair]

Yes, I was referring to Git tags (sorry for not being precise).

If you need to re-trigger builds frequently without code changes, this sounds like a problem with your CI pipeline stability. If it happens once in a while, why not trigger the build manually in Jenkins (if your devs have access to it)?

[ysabri]

I get what you are saying but here is the deal with our situation.

The devs do have access to the pipelines but we don't expose any way for them to change the Git ref (branch, tag, or committish) as a pipeline parameter. The pipeline runs and deploys to dev by default.

In the case of a PR, the pipeline checks if bitbucket PR is the run cause and then deploys to dedicated env using the PR #. Exposing that to the devs would be confusing and won't work since we have a script that will periodically clean closed PR envs. Moreover, our PR merge is contingent on a build passing on the last commit.

From a normal day to day perspective the feature I am asking for sounds like an exception, but for setting things up, fixing issues and adding new CI functionality, it is really helpful.

I'm also saying this based on the fact that we had it in an older tool that fell out of support.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.