> For the complete documentation index, see [llms.txt](https://docs.kyso.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kyso.io/posting-to-kyso/connect-a-github-repo-to-kyso/bitbucket.md).

# Bitbucket

## Prerequisites

* Have a Kyso account - either on kyso.io or on your company's private Kyso installation.
* Create a Kyso access token - follow these [instructions](https://docs.kyso.io/posting-to-kyso/kyso-command-line-tool/authorization#access-token). **Save this for later!**
* Ensure your directory (or [folders](/posting-to-kyso/publishing-faq/meta-reports.md)) contains a valid `kyso.yaml` file. Check the following [instructions](https://docs.kyso.io/posting-to-kyso/configuring-report-metadata) for more info.

## How to publish to Kyso with Bitbucket CI Pipelines

{% hint style="danger" %}
About the `kyso-push` step variables:

* The`username`and `token` fields take their value from secret variables, to make the system work the user has to create the kyso auth token and define the `KYSO_USERNAME` and `KYSO_TOKEN` as explained on the [github documentation](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
* Create your Access Token according to this document: <https://docs.kyso.io/posting-to-kyso/kyso-command-line-tool/authorization#access-token>
* The`url` has to point to your **Kyso** deployment. So if your company, Acme Inc. has its own **Kyso** instance available on <https://acme.kyso.io>, that is the value that has to be assigned to it.
  {% endhint %}

In the root directory of the repository, create a`bitbucket-pipelines.yml` that details the actions we want to run and when:

```
image: node:18

pipelines:
  branches:
    main:
    - step:
        name: 'Publishing to Kyso'
        trigger: 'automatic'
        script:
          - npm install -g kyso
          - kyso login --kysoInstallUrl https://kyso.io --provider kyso --username [YOUR EMAIL] --token [YOUR ACCESS TOKEN]
          - kyso push
```

{% hint style="warning" %}
Note that \`--kysoInstallUrl\` needs to point to your company's Kyso deployment. So if your company, Acme Inc., has their Kyso on <https://acme.kyso.io>, then that is your install url address!
{% endhint %}

So now every time we make a commit to this repository, whether on the UI or from the Command Line, the above script will be run, publishing and updating our work in Kyso.

Note that this is a super simple template using the example Starter pipeline configuration, but this can be integrated into much more powerful pipeline flows.&#x20;

For example, you can decide to only push specific branches or tags.

{% hint style="info" %}
Don't see or can't figure out how to set up your desired workflow? Simply reach out to us, let us know your use case and how you want your pipeline to work, and we'll send you the documentation!!
{% endhint %}

## Executing the CI Pipeline

Using our example repository from above, as we commit changes to the Bitbucket project, a Docker image is created to run our job. We can check out the pipeline logs at `https://bitbucket.org/user/repository/pipelines`. Clicking into one of the most recent successful merges, we should see something like this:

<figure><img src="/files/CvN4qrD7XebRkhJIR6ZX" alt=""><figcaption><p>Bitbucket Pipeline</p></figcaption></figure>

## Maintaining a QA process with Pull Requests

Similar to our documentation on Github Actions, [we can maintain a QA process, ensuring only merged/reviewed work is pushed upstream to Kyso.](https://docs.kyso.io/posting-to-kyso/connect-a-github-repo-to-kyso/github#maintaining-a-qa-process-with-pull-requests)

{% content-ref url="/pages/tRU6GKqaWClzv4Wq89uz" %}
[Github](/posting-to-kyso/connect-a-github-repo-to-kyso/github.md)
{% endcontent-ref %}

So, for example, if you work with a team of scientists, data scientists, etc.., all pushing and pulling to and from the same repository, you're going to want to control how, when and what changes get published to Kyso.&#x20;

{% hint style="success" %}
Because a merged pull request always results in a push, we can just use the push event to accomplish our goal. So the above workflow will run when a PR is merged or when a commit is made directly to the master branch.
{% endhint %}

To make this workflow even more secure, it has been recommended that you **add branch protection rules to your main branch!**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kyso.io/posting-to-kyso/connect-a-github-repo-to-kyso/bitbucket.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.