Run pipeline on the result of the pull request merge commit

Issue #13867 open
Ondrej Huta
created an issue

When creating pull request, pipeline was already executed for target and branch, where the tests succeeded, but when you actually merge those two, the test will fail.

I know this is extreme and we had to create special test case, but it may happen in real life.

Expected: Default/target branch pipeline should be executed on the merged code.

Comments (16)

  1. Ondrej Huta reporter

    Today we've come to a real life scenario, in Node.JS.

    In one branch, someone starts using previously unused module (require).

    In the other, someone lints, and removes the unused require, set to warnings.

    Both will work, individually, but will break after merge.

  2. Matt Ryall staff

    We'd like to make running merge commits the default for builds triggered by pull request creation, tracked as #13438. This is the way other tools work, and it makes most sense to me.

    That issue is currently on our medium term roadmap, so potentially up for development early next year.

  3. Tilzmatic Tech

    It's a pity that this feature isn't available. It available with all the competitor gitlab,github,travis.

    To avoid directly pushing to master and develop, I have added a branch restriction on pushing. But when a feature branch is merged to develop, Pipeline is not triggered !! WTF !!

    Build time is expensive and I generally disable the pipeline for all branches other than master and develop. Please prioritize this feature, otherwise no point in using the pipeline.

  4. Vasyl Boroviak

    This should be marked as "Bug" instead of "Enhancement". A merge commit is reporting another commit's build status - this is very wrong. Such "minor" issue can (and already did in our case) cause major damage.

  5. Aneita Yang staff

    Hi everyone,

    Thanks for your interest in this issue.

    We recently released a feature to our alpha customers which lets them configure pipelines to run only when a pull request is open on the branch (#13438). This feature will be available to all customers shortly and comes with 2 new variables that are available when the pull-request pipeline is executed:

    • $BITBUCKET_PR_ID : the ID of the pull request
    • $BITBUCKET_PR_DESTINATION_BRANCH : the name of the destination branch of the pull request. $BITBUCKET_BRANCH is also available, which points to the source branch of the pull request.

    By using the $BITBUCKET_PR_DESTINATION_BRANCH variables you can merge in the destination branch at the beginning of your step (which will effectively give you the merge commit and run the pipeline on the merge result). The first step of your pipeline would then look something like this:

    step:
        - git checkout $BITBUCKET_PR_DESTINATION_BRANCH
        - git merge $BITBUCKET_BRANCH
        - <rest of your pipeline>
    

    You can check out our documentation to find out more about the feature.

    I'd love to understand whether this is suitable for your use cases. If this doesn't suit the needs of your team, can you please elaborate on why?

    Thanks!
    Aneita

  6. Vili Forsell

    Hmm, personally the flow in my mind would go along the lines of:

    First, developer pushes feature/blahblah to remote.

    Second, developer is happy with his work, so he does a pull request.

    Third, at the time of pull request submission, the code in the reviewed branch is automatically tested and checked for code coverage. This ensures that all reviewed code has run through basic unit and code coverage checks. Reviewer won't waste his time looking at incomplete code. Developer need not remember to explicitly run a build or the tests before merge checks etc.

    Fourth, reviewer reads the code that passes all tests. Reviewer decides to merge the commit to develop.

    Fifth, merge triggers the more time consuming smoke/system tests.

    Sixth, once all tests pass, it becomes part of develop.

    Thus, every merge in develop is fully functional and production-ready code; no automated testing will come afterwards. Additionally, this means that the iteration cycle is as short as possible, and we have no need for nightly builds until we have so many commits we have to delay the pipeline to save build minutes.

    In other words, the only actions people have to do are:

    1. developer does a pull request
    2. reviewer merges the commit

    ... and it result into a fully tested and buildable code in develop, that we are, manual testing aside, ready to release whenever.

  7. Emmanuele Massimi

    As for our team, we have developer branches that are deployed to temporary infrastructure when a PR is opened so that reviewers can both check the code and test functionality. Once a PR is merged/rejected, we'd like to destroy these resources automatically (currently we have a manual step to do that, however, people might forget to press it, leading to multiple deployments not being destroyed, resulting into increased costs).

  8. Log in to comment