POST /repositories/{workspace}/{repo_slug}/commit/{commit}/statuses/build
Creates a new build status against the specified commit.
If the specified key already exists, the existing status object will be overwritten.
Example:
curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repo/commit/e10dae226959c2194f2b07b077c07762d93821cf/statuses/build/ -X POST -u jdoe -H 'Content-Type: application/json' -d '{
"key": "MY-BUILD",
"state": "SUCCESSFUL",
"description": "42 tests passed",
"url": "https://www.example.org/my-build-result"
}'
When creating a new commit status, you can use a URI template for the URL.
Templates are URLs that contain variable names that Bitbucket will
evaluate at runtime whenever the URL is displayed anywhere similar to
parameter substitution in
Bitbucket Connect.
For example, one could use https://foo.com/builds/{repository.full_name}
which Bitbucket will turn into https://foo.com/builds/foo/bar
at render time.
The context variables available are repository
and commit
.
To associate a commit status to a pull request, the refname field must be set to the source branch of the pull request.
Example:
curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repo/commit/e10dae226959c2194f2b07b077c07762d93821cf/statuses/build/ -X POST -u jdoe -H 'Content-Type: application/json' -d '{
"key": "MY-BUILD",
"state": "SUCCESSFUL",
"description": "42 tests passed",
"url": "https://www.example.org/my-build-result",
"refname": "my-pr-branch"
}'
Servers
- https://api.bitbucket.org/2.0
Path parameters
Name | Type | Required | Description |
---|---|---|---|
commit |
String | Yes |
The commit's SHA1. |
repo_slug |
String | Yes |
This can either be the repository slug or the UUID of the repository,
surrounded by curly-braces, for example: |
workspace |
String | Yes |
This can either be the workspace ID (slug) or the workspace UUID
surrounded by curly-braces, for example: |
Request headers
Name | Type | Required | Description |
---|---|---|---|
Content-Type |
String | Yes |
The media type of the request body.
Default value: "application/json" |
Request body fields
Name | Type | Required | Description |
---|---|---|---|
refname |
String | No |
The name of the ref that pointed to this commit at the time the status object was created. Note that this the ref may since have moved off of the commit. This optional field can be useful for build systems whose build triggers and configuration are branch-dependent (e.g. a Pipeline build). It is legitimate for this field to not be set, or even apply (e.g. a static linting job). |
name |
String | No |
An identifier for the build itself, e.g. BB-DEPLOY-1 |
description |
String | No |
A description of the build (e.g. "Unit tests in Bamboo") |
key |
String | No |
An identifier for the status that's unique to its type (current "build" is the only supported type) and the vendor, e.g. BB-DEPLOY |
url |
String | No |
A URL linking back to the vendor or build system, for providing more information about whatever process produced this status. Accepts context variables |
uuid |
String | No |
The commit status' id. |
created_on |
String | No | |
type |
String | Yes | |
updated_on |
String | No | |
state |
String | No |
Provides some indication of the status of this commit Possible values:
|
links |
Object | No | |
links.commit |
Object | No |
A link to a resource related to this object. |
links.commit.href |
String | No | |
links.commit.name |
String | No | |
links.self |
Object | No |
A link to a resource related to this object. |
links.self.href |
String | No | |
links.self.name |
String | No |
How to start integrating
- Add HTTP Task to your workflow definition.
- Search for the API you want to integrate with and click on the name.
- This loads the API reference documentation and prepares the Http request settings.
- Click Test request to test run your request to the API and see the API's response.