Can a bitrise "build" be triggered from more than one repository?

Question & Answer
1

I have two repositories and a change in either one should produce an app. Can I trigger based on pushes or pull requests in either repo?

2

Hi @eugeneshih!

Thanks for asking this here! :wink:

Well, technically it is possible to do something like that, but it might not be that simple.

How do you “link” you repositories? As submodules? Or as dependencies (e.g. as a CocoaPods pod)? Or just with a custom Script step with git clone?

3

Currently, I use Cocoapods to link the repositories. So, the building part is easy. But I would need a step to git clone the dependency.

4

You most likely link your two repos with versions to each other. That can be through CocoaPods, or just through submodules, you specify a “version” from one repo to the other.

If you don’t, that can lead to issues in the future, e.g. when you try to rebuild your app but in the meantime the dependency was updated, so you won’t get the same build or the build won’t even work.

So, even if you do use the “latest” version of the other repo/dependency (e.g. if you don’t lock your CocoaPods dependency to a version), there’s a technical issue here. To trigger a build for “RepoMain” when “RepoDependency” changes you have to use webhooks. You can of course register the same webhook for two different repos, but in that case the webhook will include invalid infos for the other repo.

Example: you have a simple workflow with Git Clone step (which clones the specified git commit when the build is triggered through a webhook) and then a dependency download (e.g. CocoaPods Install step) and a build step.

Now, if you register the same webhook for both RepoMain and RepoDependency, the build will start for a change in either of these. BUT the webhook will include the change’s git commit, so the Git Clone step will try to clone the commit from the webhook (coming from RepoDependency) from RepoMain. This will fail, as there won’t be a commit in RepoMain for the commit hash from RepoDependency.

So, how could this be solved?
To solve this issue you’d have to trigger builds for RepoMain when RepoDependency changes, but without passing in the commit hash from RepoDependency. You could solve this with e.g. a custom webhook handler, one you write & maintain, or possibly with a service which can do this (to transform / strip e.g. a GitHub webhook), or, through a custom bitrise.io app.

The details depend on your specific requirements, e.g. whether you want to pass the dependency commit hash to the build in RepoMain, but something like this could work:

  1. Register both repos on bitrise.io, as separate apps/projects
  2. RepoMain (your app project) should be a usual bitrise.io app, you might not have to change anything there (depends on how you reference your dependency)
  3. RepoDependency would have a custom build configuration, with only one purpose, to trigger a build in RepoMain, with the parameters you want to pass to that build.
  4. A really minimal setup for RepoDependency’s project could be a single Script step, from which you trigger a build for RepoMain with a curl call, using the Bitrise.io Build Trigger API (docs)

You could of course pass over additional parameters as well, using the one-off Environment Variables option of the Trigger API, so e.g. you could share the RepoDependency project’s commit hash which started that “build” (BITRISE_GIT_COMMIT) by exposing it through the Trigger API as another env var, e.g. MY_DEPENDENCY_GIT_COMMIT. In RepoMain’s build config you could reference this env var (if/when passed) and clone that commit of the dependency repo.

So, it is definitely possible but might require quite a bit of setup, because the problem itself is not that simple. You have to answer questions like, when the dependency changes should RepoMain use that specific change (commit hash) of the dependency, or always e.g. the latest commit from “main” branch of the dependency? You might also have to tweak your dependency “download” config to be able to lock the dependency version, or to use a dynamically specified version (e.g. specified through an environment variable).

With a two bitrise.io project setup (like the one above) you can definitely do this, and you have full control over every parameter, but it might take quite some time to refine this setup.

I hope this helps, and if you have any questions, feel free to ask! :wink:

3 Likes
5

I will give this a shot. But I agree, some tweaking might be necessary.

1 Like