Environment variable for last successful commit

Issue #13805 open
Evgeniy Sokolov
created an issue

Would be nice to have COMMIT_RANGE as a env- variable, similar to https://docs.travis-ci.com/user/environment-variables/ - TRAVIS_COMMIT_RANGE

We want to check coding style for changes, but it is make no sense to check all files, and we want to check only changes between in this build.

It would be nice if range will be started from last "successfull build".

Comments (3)

  1. Matt Ryall

    That's a good idea, thanks for the suggestion. It seems very useful, but unfortunately it will probably be a while before we have capacity to add this to Pipelines, given the other competing feature requests.

    For now, I'd suggest you probably want to come up with a script to do this yourself. Here's how I'd think about doing it:

    • use git log --format=%h -n 10 to get a list of the recent commit hashes
    • loop over these and use the Bitbucket REST API to get the build status and check for "state": "SUCCESSFUL" in the response.

    Here's a shell script snippet that you might be able to adapt:

    for COMMIT in `git log --format=%h -n 10`; do
        curl --user '$BB_USER:$BB_PASS' 'https://api.bitbucket.org/2.0/repositories/$BITBUCKET_REPO_OWNER/$BITBUCKET_REPO_SLUG/commit/$COMMIT/statuses/'` | \
            grep -q 'SUCCESSFUL' && \
            echo "$COMMIT was successful"

    You can create a read-only app password to configure the $BB_USER and $BB_PASS environment variables in your pipeline.

  2. Matt Ryall

    Reviewed 22 Feb 2018 - leaving open. I like this idea because it fits with the "fixed" status that we're working on now, which we will calculate when sending notifications. Seems like it might be easy to address at the point where we do that, and enable some important use cases for customers.

    Note that what Travis does is different. Their TRAVIS_COMMIT_RANGE variable provides the range of commits in the push (or pull request), not the commits since the last build (successful or otherwise). Depending on what functionality we offer here, we might want to use a different name to minimise potential confusion.

  3. Log in to comment