Storing the bitrise.yml in a privately hosted repository – Bitrise

You can store your bitrise.yml file in your own repository. However, if your app uses a repository where the service credential user integration is not supported - for example, the repository is only accessible under a private IP subnet -, the feature won't work as the website can't grab the bitrise.yml due to IP addressing limitations. There is a workaround though: we’ll define a wrapper configuration which will then run the build on Bitrise, using a bitrise.yml stored in the repository.

Enterprise-level applications

The workaround described here works both for GitHub Enterprise and Bitbucket Server users.

A wrapper config means setting up a bitrise.yml configuration on bitrise.io: this configuration defines how the actual bitrise.yml file you want to use will be retrieved from the repository.

The wrapper configuration will contain an automatically triggered Workflow, and another one that will tell Bitrise to continue the build from the repository. To make this work, we take advantage of a Script Step and the $BITRISE_TRIGGERED_WORKFLOW_ID environment variable. This environment variable is automatically set to the Workflow that triggered the build: if we have a Workflow with the same name defined in the bitrise.yml file that is stored in the repository, we can run that Workflow.

In our example, we’ll use:

A trigger map where the ci Workflow is triggered by code push to the master branch.
A Workflow called run_from_repo to tell Bitrise to continue the build from the repository.
A Workflow called ci with an after_run attribute set to the run_from_repo Workflow.

In this example, a code push will trigger the ci Workflow, which in turn triggers the run_from_repo Workflow. The run_from_repo runs a Script Step which runs the bitrise run ci command in the repository. Let’s do it!

The trigger map is better managed on bitrise.io

You can store the trigger map in the bitrise.yml of your repository - but we don’t recommend it. You’ll lose the ability to SKIP builds. On bitrise.io, the trigger map is evaluated BEFORE the repository is cloned: this way, for example, if you set the patterns correctly in code pushes or pull requests, then Bitrise won’t even start those builds which don’t match the set patterns.

However, if you store the trigger map in your repository, the only way to check it is to clone the repository first. Even if you prepare your trigger_map in your repository, bitrise.io will start a build to clone the repository and you have to manually handle the stored trigger map.

Pull Requests can run builds with any configuration

When someone sends a Pull Request they can modify the bitrise.yml in your repository any way they like it. This can force your builds to queue.

You can't rebuild a specific commit with a different configuration

Storing the bitrise.yml file in your repository has a significant drawback when you want to rebuild a specific commit, it will use the same bitrise.yml every time: the one stored in the repository for that git commit.

To change the configuration, you have to check out the related branch, change the bitrise.yml, commit the changes, and then push and start a new build.

Open your app on bitrise.io.
Open the Workflow Editor and go the bitrise.yml tab.

Set up a trigger map that automatically triggers a specific Workflow.

---
format_version: 5
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git 
trigger_map: 
- push_branch: "*"
  Workflow: ci 
- pull_request_target_branch: "*" 
  Workflow: ci

Set up the Workflow that is triggered by the trigger map.

This Workflow must have an after_run attribute that points to another Workflow.
```
ci: 
  after_run: 
  - run_from_repo
```

Set up the Workflow that is triggered by the after_run attribute.

This Workflow must have:

A Git Clone Step to clone your repository.

A Script Step with the command bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}.

Workflows: 
  run_from_repo: 
    steps: 
    - activate-ssh-key: 
        run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' 
    - git-clone: {} 
    - script: 
        title: continue from repo 
        inputs: 
        - content: |- 
        #!/bin/bash set -ex 
        bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}"

Create a bitrise.yml file that contains all the Workflows defined in the trigger map of the wrapper configuration.
Commit the file to your repository.