concourse-resource-bitbucket
This is a fork of https://github.com/ecometrica/concourse-resource-bitbucket, which in turn forked https://github.com/Karunamon/concourse-resource-bitbucket. This fork is substantially changed from the original.
Summary of changes:
- Targets bitbucket api version 2 instead of 1.
- Only targets bitbucket.org.
- Change auth from user/password to OAuth client credentials grant.
- Support both hg and git repos.
- Create an automated docker build.
- Uses unittests instead of behave for tests.
- Post correct URLs to Bitbucket when using multiple teams in concourse
You can find a pre-built Docker image on DockerHub. The build of the docker image is using the docker hub automated build. The builds will run the tests to make sure that a broken image is never pushed.
Creating an Access Token
You need to create an OAuth access token for your github team/user account with the following permissions: Webhooks (r/w), Repositories (r)
Make sure to provide a callback URL (it's not needed at runtime but Bitbucket insists on it anyway). For example, you can use the URL of your concourse instance. Otherwise you will see an error similar to the following
Access token result: <Response [400]>{"error_description": "No callback uri defined for the OAuth client.", "error": "invalid_request"} HTTP 401 Unauthorized - Are your bitbucket credentials correct?
Resource Configuration
These items go in the source fields of the resource type. Bold items are required:
client_id- Client id of the OAuth consumer. Shown asKeyin the bitbucket interface.secret- Secret for the OAuth consumer.repo- Full repository name on bitbucket to set build status in. (<username>/<reponame>).debug- When True, dump the JSON documents sent and received for troubleshooting. (default: false)
Behavior
check
No-op
in
No-op
out
Update the status of a commit.
Parameters:
-
repo- Name of the git repo containing the SHA to be updated. This will come from a previousgeton agit/hgresource. Make sure to use the resource directory name, not the name of the resource. -
state- the state of the status. Must be one ofSUCCESSFUL,FAILED, orINPROGRESS- case sensitive.
Example
A typical use case is to update the status of a commit as it traverses your pipeline. The following example marks the commit as pending before unit tests start. Once unit tests finish, the status is updated to either success or failure depending on how the task completes.
resource_types:
- name: bitbucket-notify
type: docker-image
source:
repository: ecometrica/concourse-resource-bitbucket
resources:
- name: testing-repo
type: git
source:
uri: https://bitbucket.org/someuser/somerepo.git
branch: master
- name: bitbucket-notify
type: bitbucket-notify
source:
client_id: cid
secret: hemligt
repo: user/repo
jobs:
- name: integration-tests
plan:
- get: testing-repo
trigger: true
- put: bitbucket-notify
params:
state: INPROGRESS
repo: testing-repo
- task: tests
file: testing-repo/task.yml
on_success:
put: bitbucket-notify
params:
state: SUCCESSFUL
repo: testing-repo
on_failure:
put: bitbucket-notify
params:
state: FAILED
repo: testing-repo
In this example, notice that the repo: parameter is set to the same name as the testing-repo resource.
To reiterate: In your deployment, set the repo: field to the folder name of the git repo, or in other words,
what you'd end up with if you ran a git/hg clone against the URI.
Low hanging improvement fruit
This is a work in progress and there are multiple areas that could use some improvement. Any contribution is welcomed.
- Need to specify the repo explicitly in the source parameters. Change this to read the correct remote url from the repo itself.
- Add back support for self hosted bitbuckets.
- Write more tests.
References
Thanks
- Karunamon for getting the ball rolling.