This is a fork of https://github.com/Karunamon/concourse-resource-bitbucket. The following forks have been merged in, too:
- https://github.com/Fydon/concourse-resource-bitbucket
- https://github.com/mehtaphysical/concourse-resource-bitbucket
- https://github.com/aecepoglu/concourse-resource-bitbucket
- https://github.com/ecometrica/concourse-resource-bitbucket
- https://github.com/Meshcloud/concourse-resource-bitbucket
You can find a pre-built Docker image on DockerHub.
If you come from one of the integrated forks, you can use the image with tag compatibility
, which should work without you changing anything else.
These items go in the source
fields of the resource type. Bold items are required:
debug
- Optional. Default:false
. Whentrue
, dump the JSON documents sent and received for troubleshooting.driver
- Optional. Default:Bitbucket Server
. The driver to use to set the build status.
There are two supported drivers, with their own sets of properties for configuring them.
repository
- Required. Full (<ownername>/<repositoryname>
) repository name on Bitbucket Cloud to set build status for.repo
- Required. DEPRECATED. Userepository
instead. Full repository name on bitbucket to set build status in. (<ownername>/<repositoryname>
).owner
- Required. DEPRECATED. Userepository
instead. The owner of the repository, which will either be a username or team.repository_name
- Required. DEPRECATED. Userepository
instead. The name of the repository on Bitbucket Cloud.
One of the following two sets of properties must be specified:
username
- Required. Login name.password
- Required. An app password with permission to read from and write to a repository.
client_id
- Required. Client id of the OAuth consumer. Shown asKey
in the bitbucket interface.client_secret
- Required. Client secret of the OAuth consumer.secret
- Required. DEPRECATED. Useclient_secret
instead. Client secret of the OAuth consumer.
You need to create an OAuth access token for your Bitbucket Cloud 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 OAuth 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?
endpoint
- Required. URL to a Bitbucket Server instance.username
- Required. Login name of someone with rights to the repository which's build status should be updated.password
- Required. Password associated with that login.verify_ssl
- Optional. Default:true
. Whenfalse
, ignore any HTTPS connection errors if generated. Useful if on an internal network.bitbucket_url
- Required. DEPRECATED. Useendpoint
instead. URL of the bitbucket instance, including a trailing slash.bitbucket_username
- Required. DEPRECATED. Useusername
instead. Login username of someone with rights to the repository being updated.bitbucket_password
- Required. DEPRECATED. Usepassword
instead. Password for the mentioned user.
-
repository
- Required. Name of the repository containing the commit whose build status should be updated. This will come from a previousget
on agit/hg
resource. Make sure to use the directory name, not the name of the resource. -
build_status
- Required. The build status. Must be one ofSUCCESSFUL
,FAILED
, orINPROGRESS
. -
key
- Optional. Default:ENV['BUILD_JOB_NAME']
. Use the given key in build notification. If different notifications have the same key, they will replace each other. -
name
- Optional. Default:ENV['BUILD_NAME']
. Use the given name in build notification. This will show up on Bitbucket. For example "unit tests", "end to end tests" -
build_url_file
- Optional. Link to the URL given in the file. If not specified, the build status will link to<concourse-url>/teams/<team>/pipelines/<pipeline>/jobs/<job>/builds/<build>
. -
description_file
- Optional. A path to a file containing a description of the build. For example: "7 tests have failed". If not specified, the description will default to"Concourse CI build, hijack as #<build-id>"
. -
commit_hash_file
- Optional: A path to a file containing a commit hash. When specified,repository
is no longer required and this option takes precedence. This is useful in case you don't have the repository checked out or you have logic inside a task that computes the correct commit to update. -
repo
- Required. DEPRECATED. Userepository
instead. Name of the repository containing the commit hash to be updated. This will come from a previousget
on agit/hg
resource. Make sure to use the directory name, not the name of the resource. -
state
- Required. DEPRECATED. Usebuild_status
instead. The build status. Must be one ofSUCCESSFUL
,FAILED
, orINPROGRESS
.
A typical use case is to update the build 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 build status is updated to either success or failure depending on how the task completes.
resource_types:
- name: bitbucket-build-status
type: docker-image
source:
repository: shyxormz/bitbucket-build-status-resource
resources:
- name: testing-repo
type: git
source:
uri: https://bitbucket.org/someuser/somerepo.git
branch: master
- name: build-status
type: bitbucket-build-status
source:
client_id: cid
client_secret: hemligt
repository: someuser/somerepo
jobs:
- name: unit-tests
plan:
- get: testing-repo
trigger: true
- put: build-status
params:
build_status: INPROGRESS
repository: testing-repo
- task: tests
file: testing-repo/task.yml
on_success:
put: build-status
params:
build_status: SUCCESSFUL
repository: testing-repo
on_failure:
put: build-status
params:
build_status: FAILED
repository: testing-repo
In this example, notice that the repository
parameter is set to the same name as the testing-repo
resource.
To reiterate: In your deployment, set the repository
field to the directory name of the repository, or in other words,
what you'd end up with if you ran a git/hg clone
against the URI.
To install on all Concourse workers, update your deployment manifest properties to include a new groundcrew.resource_types
entry...
properties:
groundcrew:
additional_resource_types:
- image: "docker:///shyxormz/bitbucket-build-status-resource#latest"
type: "bitbucket-build-status"
To use on a single pipeline, update your pipeline to include a new resource_types
entry...
resource_types:
- name: bitbucket-build-status
type: docker-image
source:
repository: shyxormz/bitbucket-build-status-resource
tag: latest
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.
- Fix tests.
- Write more tests.
- Karunamon for getting the ball rolling.