Motivation

In my mobile dev team, we actively use Bitrise to automate the processes of nearly 80 apps. For version control, we’re using GitHub — a good pairing in most cases, but not without its hurdles (hence this post). To increase testability of our mobile apps, we wanted to create a crawler that extracts API responses from our test backend and stores them as JSON files, so that we can include these in our apps as mock data.

To achieve this, I started to develop a new app in Bitrise. Running this script saves 109 JSON files from 6 different endpoints into the directory called mocks. I want to automatically push the latest mock data files after each run to another Git repository so that our mobile apps can include them, so I’ve set up the mocks directory as a Git submodule in the crawler project.

I’ve built my first Bitrise workflow for the crawler with the default Git clone configuration and failed miserably because of Git permission issues. Both Git repos should have the same SSH or deployment keys so we need some additional work here.

But… it turned out that GitHub does not support having the same SSH keys as deployment keys on multiple projects, therefore as the FAQ page suggests (read the details here), I had to create a new bot/machine user on GitHub.

How to set up submodule workflows with a machine user?

1. Register a new GitHub account

I’ve registered ours with a Gmail address that we are also using as an Apple id and Google Play account. I’ve also saved all the credentials in 1password (choose your weapon), so if anything happens with me, my teammates will be able to continue the work. Let’s call our user ci-user.

You have to add ci-user as a collaborator to all of the repositories you want to access. I am adding my user to 3 projects:

• _mobile_mock_crawler
• _mobile_mock
• _mobile

2. Generate an SSH key

You also have to get an SSH key for ci-user.
To generate it, open up your parent project’s Bitrise app and go to Settings.

Scroll down to the Change SSH keypair section and choose the Generate SSH keypair option.

Copy both the public and the private keys of your SSH key (also save it to 1password)!

Now head back to GitHub and add the public key in the Settings / SSH and GPG keys section (http://github.com/settings/keys) for ci-user. Press the New SSH key button and paste your public key into the Key field.

It’s alive! Bitrise can access your user and the Git permission issues are gone, the git-clone step succeeds. But as one of our projects is generating the other one, we can have additional steps.

3. Pull submodules

If you want to pull the freshest commits from your submodule, add a script step and pull it.

4. Set up automatic Git push and pull requests

Now let’s add the automatic push and pull-request recording to our workflow. To install our dependencies add a Brew install step and add hub as the name of the formula.

Add a script step and add these lines:

Now every time I run our crawler project’s Bitrise workflow

• it gets and pulls the submodule(s)
• runs and generates the JSON files into the submodule
• creates a branch and pushes the changes
• records a pull request on GitHub

Now the only thing I have to do is schedule this workflow or press the build button manually (and merging a PR) to have the freshest data JSON dump from our test backend in our mock data repo automatically.

5. The Butterfly-effect

Now we can add the mock data repo as a submodule to our mobile projects.
That’s bringing some additional steps for us, as we have to configure our mobile project’s Bitrise app to use the ci-user’s SSH key.

Open up the mobile project’s Bitrise app page and then the Settings page. Scroll down to the Change SSH keypair section and choose the Use your own SSH keypair option.

The UI confusing a bit here, so pay attention now to copy the private(!) key of your SSH key even though the button says “I’ve added the Public key”!

That’s it. With this technique, you can use the same SSH key for all of your GitHub projects.

That worked so well that I’ve added the SSH key for all of our other projects as well, so we have a real CI bot/machine user now!