Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tim Black
    @timblaktu
    Bitbucket Server Notifier plugin?
    I would like to keep using build status reporting that I'm getting from BB Server Notifier plugin, which is shown per commit in bitbucket's commits views (inside and outside a PR context) but in PR views I would like to use PR builder plugin's build status (since it supports performing the build on a merged to Target branch working copy, and thats really the important metric to track before allowing a merge).
    Tim Black
    @timblaktu
    Is it possible to use both concurrently, or do I have to pick one or the other? It seems like bit buckets build status reporting API is a per commit interface, so the reporting done by these two plug-ins is identical and therefore hard to differentiate.
    I guess one way to accomplish what I want would be to make the build status reporting conditional in my pipeline, such that when the build is triggered by a PR event (i.e. your plugin's triggers), I use your plugin's reporting, else I would use BB Server Notifier's reporting mechanism.
    Let me know if anyone else has other ideas for how to accomplish this. Stay healthy y'all.
    .
    Tim Black
    @timblaktu
    I know Bitbucket collects a list of build status per commit. So, I suppose I could just have both plugins report build status for the same commit in a PR context, one for the source branch build, and one for the merged-to-target-branch build. Then a sensible (and thorough) merge check would be to see "Minimum Number of Successful Builds" to 2. The merge check can't differentiate between the source build status and the merged Target build status, however with the above approach I think I'd get the desired result. Thoughts?
    WrzocHoo
    @WrzocHoo
    They are unrelated. You could use both at the same time. Notifier and stash pull request.
    jakub-bochenski
    @jakub-bochenski
    @timblaktu I don't quite understand your problem. This plugin doesn't report build status via the stash API.
    Tim Black
    @timblaktu
    News to me, thanks. So, its purpose is only to provide a set of PR event triggers?
    jakub-bochenski
    @jakub-bochenski
    I suggest you check out the readme, all the functions are described there
    typically one would use it together with the notifier plugin to get results on commits via stash API
    Tim Black
    @timblaktu
    Thx, will peruse it more closely. I've noticed there's an active "stash pullrequest builder" plugin project as well, that appears to be distinct from this one. Also the "Push and Pull Request" plugin. Can anyone here speak to the differences? I am using BBS 6.10.1. so far from what I've read it looks like you're a plug-in is the best one to try. The big difference I've been able to see, is the support for merging to target before build, but this would appear to be something that any job could do pre-build if it knew the target branch.
    Tim Black
    @timblaktu
    I'm comparing this plugin to "Bitbucket Pull Request Builder" and "Bitbucket Push and Pull Request" plugins. Anyone know the differences? It's very confusing why there are three such similar plugins.
    Tim Black
    @timblaktu
    Interesting, I just posted the last msg here thinking there was a separate gitter channel for "Stash Pull Request Builder". I thought they were distince, since there are separate github projects, and in my jenkins instance when I go to "Available Plugins" I see both as separate distinct plugins. Can someone please explain the history here, I'm very confused about these projects with almost the same name, the very same gitter channel, but quite different functionality as described on their github pages.
    Tim Black
    @timblaktu
    @jakub-bochenski , the first sentence in https://github.com/jenkinsci/stash-pullrequest-builder-plugin/blob/master/README.md is: "This Jenkins plugin builds pull requests from a Atlassian Stash server and will report the test results as a comment." I see in the section here: https://github.com/jenkinsci/stash-pullrequest-builder-plugin#notify-stash-of-build-result, that it implies you need to use Notifier plugin to report build status. Seems like the first sentence in the README is wrong?
    Ghost
    @ghost~5db8a593d73408ce4fcf630e
    Greetings - does the (re)test build phrase support multiple comma delimited phrases, like the disable build phrase does?
    The help for the field doesn’t say so, and I can’t seem to get it to work - but I am unsure if it’s supposed to work.
    If it’s not supposed to work, I wonder why this feature was omitted?
    Liam
    @wreimers
    Sorry - was using the wrong account.
    Those questions are from me.
    Pavel Roskin
    @proski
    @timblaktu The first sentence in README.md is correct. Stash Pull Request Builder plugin reports the build status as a comment. Stash Notifier is not needed for that. Stash Notifier uses a different API, it doesn't post any comments.
    jakub-bochenski
    @jakub-bochenski
    sorry for missing the mention
    the Stash Notifier plugin is optional, however you will need it if you want to block builds based on build result etc.
    Greetings - does the (re)test build phrase support multiple comma delimited phrases, like the disable build phrase does?
    the trigger just check if the phrase is included in a comment (fragment match, case insensitive)
    Gregory Paciga
    @gpaciga
    Hi all - I'm starting to work with pipelines, and came across the limitation about no customization of the comment text. Has anyone looked into adding that feature? I'm going through old issues around pipelines now, but thought it might be good to ask in case there's an easy answer, either "it's impossible because..." or "it's easy but nobody's bothered to do it yet"
    Pavel Roskin
    @proski
    @gpaciga The comment customization is currently configured in the post-build actions, not in the main trigger configuration. Pipelines don't show the post-build action GUI. I believe the customization should be moved to the main GUI. In fact, the code doesn't even post the comments from the post-build action, it posts from the onCompleted() method of RunListener associated with the build. Changing GUI means that the old configuration needs to be converted to the new configuration on upgrade, which requires configuration conversion code. When things move around, there are always confused users and a lot of questions. I just did not feel the comment customization was an important feature compared to the required effort to make it available in pipelines.
    Gregory Paciga
    @gpaciga
    Thanks for the response @proski . In the meantime I had put a ticket in the issue tracker for the feature request, it might be worth commenting there with what makes it difficult? I admit my knowledge of plugins is not really enough to follow, but maybe someone who wants the same later will find that ticket. As you'll see, I actually came up with a workaround to post a comment using the existing code, which I'm now using from a shared library. It results in two comments instead of one, but it works for now.
    jakub-bochenski
    @jakub-bochenski
    @gpaciga migrating plugin data isn't all that hard, you just need to write code to read the old values and convert them to new, there's a section describing it in the Plugin Development documentation
    BTW one thing I've been wanting to change for some time is how this plugin relies on comments to keep state,
    however this will probably just change the state-resolution logic, not the way comments are posted (and that item is also just my wishlist, other commitments keep getting in the way)
    jakub-bochenski
    @jakub-bochenski
    PS. if double comments are annoying you could try two separate users and ignoring notifications from one of them (I think it's doable in stash, but didn't neeed it myself)
    Pavel Roskin
    @proski
    Using comments to track state is indeed "low-tech", and that's another reason why I didn't want to touch the customization.
    I plan to give the Bitbucket Branch Source Plugin another try. It supports Jenkinsfile from a managed file now. Using files under version control wasn't a good option for me.
    Gregory Paciga
    @gpaciga
    Yeah, as I'm getting deeper into pipelines, Bitbucket Branch Source works quite well for triggering builds on pull requests in a Multibranch job. Though I still use this plugin to do the PR comments
    Pavel Roskin
    @proski
    I actually had a chance to try Bitbucket Branch Source again. They addressed my two complaints I had the last time - it's possible to disable the job globally and there is a way to provide and external Jenkinsfile. However, my team uses a script to test intermediate commits in pull requests, and there is no option for that in Bitbucket Branch Source. Stash pull request builder is still more flexible for specialized use. Also, the Bitbucket Branch Source GUI is quite confusing and overwhelming. I enabled testing of all branches by mistake, and the plugin started 500 builds at once, bringing Jenkins down. The default should be to test nothing, and there should be provisions to prevent the overload even if the user wants to test all branches.
    harasai
    @harasai

    Hi,
    We are experiencing that pull requester not able to trigger the jobs in jenkins, when commented with the phrase specified at "Phrase to request a (re-)build" in PR. we have two phrases, build, build this please. Some times builds can trigger with build some times trigger with build this please. Some times I suppose to keep only one phrase. Developers are habitat to use the phrases either build or build this please.

    Can You please let me know what could be the blocker.

    jakub-bochenski
    @jakub-bochenski
    AFAIR you can only have one phrase
    if it's found in a comment it will trigger a build
    harasai
    @harasai
    Hi Jakub thanks for the response. So if i keep the "build" as phrase, users can comment build or build this please, can trigger the build. Am I correct .
    harasai
    @harasai
    also i have another doubt, when the notifying back to PR, comment [BuildFinished iOS-PRDebugBuild] 8942dabd72d42e790aad1091d3435f8b9105cc7c into 115ae82b8672b603c8e56023189427ba4620ff31
    ✓ BUILD SUCCESS - Build #36531 which took 22 min will trigger the build if i keep only build as phrase. and is it case sensitive!
    Pavel Roskin
    @proski
    I confirm that there is only one build phrase. It is not split in any way. The whole build phrase is searched in the whole comments. The search is not case sensitive. "build" would be a very poor choice, as it would match any comment that contains the word "build", including the automatically posted comments. Use a phrase that is unlikely to be used accidentally. The default "test this please" is a much safer choice.
    dharmaveer972
    @dharmaveer972
    Hi ,
    I’m using stash pull request builder to trigger my pipeline script from SCM. But it is not getting triggered. Can anyone help me what could be the issue here.
    jakub-bochenski
    @jakub-bochenski
    maybe try checking Jenkins logs or polling log of the job
    dharmaveer972
    @dharmaveer972
    I’m not using poll scm, but using cron schedule in the stash pull request builder
    Pavel Roskin
    @proski
    @dharmaveer972 Please use the latest version of the Stash Pull Request Builder plugin (1.17), it has the "Polling Log" link on the job page. It has nothing to do with the "Poll SCM" trigger.
    Mike Snodgrass CSAA
    @MikeSnodgrass-CSAA
    Hi! We recently upgraded to Bitbucket Server 7.6, from 6.9. We are seeing build errors with "Couldn't find any revision to build." It appears that Bitbucket Server 7.0 removed support for 3-way diffs, and since there is no longer a merge ref that CI systems can build, there are no build statuses to detect. Anyone had success with Bitbucket Server 7.0+ with the plugin?
    Pavel Roskin
    @proski
    @MikeSnodgrass-CSAA I installed Bitbucket 7.7.1 on my laptop and tried using Stash Pull Request Builder 1.17 with it. It worked just fine. I used the instructions from "Creating a Job" in the README. I guess you are you using the setup described under "Letting Stash do the merge". Indeed, that configuration is giving me exactly the error you have mentioned. I guess such setup should not be recommended anymore.
    harasai
    @harasai
    I am trying to build PRs except from release branch, I added the regex at targetBranchesToBuild as [^release\/.*] and builds not triggering from non release branches. May I know how to exclude release branches.
    Phil Chiu
    @whophil
    @MikeSnodgrass-CSAA @proski I'm late to the party here, but I just updated to 7.x and also lost the ability to build pull request merges via the pr//merge refspec. To have the same effect, I now have to build build ${sourceBranch} merged onto ${targetBranch} via the PreBuildMerge extension of the GitSCM checkout step (I'm using declarative pipelines). It's not nearly as elegant, but it's the only workaround I've found as it doesn't sound like pr//merge is going to come back.
    Pavel Roskin
    @proski
    @harasai It sounds like you want to control what gets build by the name of the source branch, not the destination (target) branch. Such functionality is not implemented. One possible approach would be to disable automated build and use the build phrase to trigger the build.