Bitrise YML in Repo

Hi, just got an email about storing the yaml configuration in the repository. We’ve already been doing that for a few months, with some help of the documentation that I can’t find now (maybe it was replaced with the new version?). Anyway, my question is: does this new system simply automate what we had to do until now by hand? That is, create a secondary yaml stored in bitrise that then triggers the other yaml after cloning the repo? Or is it implemented in some other way?

The advantage of doing this “by hand” is that bitrise.yml doesn’t have to be stored in the root of the repo, but can be in our scripts folder instead. The disadvantage is that all our jobs are shown as that one forwarding workflow, making them hard to distinguish in the job list…

Hello,

You aren’t crazy! We have documentation on doing just what you describe, but it was somewhat of a workaround until this solution was provided. You can still use the workaround.

For more info, check out the devcenter:https://devcenter.bitrise.io/tips-and-tricks/use-bitrise-yml-from-repository

Cathy

Hello,

thank you for responding. According to this:

Bitrise will look for the file in the root directory, and as such, currently there’s no way to include two in separate folders.

it doesn’t seem like there is a way to put the yaml file anywhere but in the root directory - is this correct?

One more question about this:

To store the file in your repository, you must commit it to the root of your Bitrise app’s default branch. You can check the app’s default branch on bitrise.io: open the app, and go to the Settings tab. Scroll down to the DEFAULT BRANCH option to check which branch should contain the bitrise.yml file.

Does that mean that bitrise will always look for the yaml file on that branch, even though a build is triggered from a different one? :thinking:

You are correct on both counts. The yaml file must be in the root directory of the default branch as specified in the Settings tab for the app. And yes, that does mean there can only be one yaml file. But you can include all workflows in that yaml file - they just need unique names.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.