We have a job setup with the trigger phrase (:)(.*). Then we have configuration code in the project that takes the variable ghprbCommentBody and uses it to identify which Gradle task to execute.
Since this can be used generically, using a static message for the Commit Status Context may be confusing, so we use the following Commit Status Context: ${ghprbCommentBody}.
This is great, because when the job runs we can see the trigger that it corresponds to. The only problem is that first the plugin posts the commit context ${ghprbCommentBody}, then later posts the expected value (see image):
The issue is that there should only be one (:test). The main issue is that the GHPRB adds a second status message instead of replacing the old one. OR this could be seen as an ordering issue with the plugin, such that the ghprbCommentBody variable should be initialized before posting the status.
We have a job setup with the trigger phrase
(:)(.*). Then we have configuration code in the project that takes the variable ghprbCommentBody and uses it to identify which Gradle task to execute.Since this can be used generically, using a static message for the Commit Status Context may be confusing, so we use the following Commit Status Context:
${ghprbCommentBody}.This is great, because when the job runs we can see the trigger that it corresponds to. The only problem is that first the plugin posts the commit context ${ghprbCommentBody}, then later posts the expected value (see image):
The issue is that there should only be one (:test). The main issue is that the GHPRB adds a second status message instead of replacing the old one. OR this could be seen as an ordering issue with the plugin, such that the ghprbCommentBody variable should be initialized before posting the status.