First class mono repo support

Just and update and a question; we did discuss this a couple of times with the team and right now we’re thinking about something like this (question is what you think about it):

We would provide an alternative webhook server as a premium feature, most likely for an additional fix cost per app, which would include the required features to fetch the file change data from GitHub/Bitbucket/…

With this, instead of the previously mentioned flow:

We could simply:

GitHub/Bitbucket/... -> PREMIUM-WEBHOOKS.bitrise.io (-> call back to GitHub/Bitbucket/.. to fetch additional infos) -> bitrise.io (start build)

From an architectural point of view this seems to be the right solution, the question is whether you’d be OK with paying ~$10/mo/bitrise.io app for this feature.

What do you think @bootstraponline & @awitherow ? Would you pay ~$10/mo/bitrise.io app for this?


A bit more info about this solution:

  • The “premium webhook” server could be built on top of the existing open source GitHub - bitrise-io/bitrise-webhooks: Bitrise Webhooks processor, in an “open core” way, so the open source version could also be improved when/if required.
  • The interface for defining the file filters could remain the Trigger Map, no additional settings would be required, the Trigger Map syntax would be extended.
  • And overall pretty much every interface/troubleshooting feature could remain the same (e.g. the ones described at Redirecting… - Bitrise Docs ), so the tooling could remain unified and you won’t have to learn about additional tools for e.g. debugging/troubleshooting.

I’d prefer this be part of the “elite tier.” The problem with billing “per app” is it isn’t per app, it’s per CI job. Mono repos mean we have an ever growing amount of jobs. Having unpredictable billing as we use the service more doesn’t make sense. It’s similar to how GitHub use to charge per repo and now they charge per user. If the billing model limits use of the service then that’s a bit strange.

Buddybuild has the right model I think. Features are based on different tiers of concurrency.

1 Like

Thanks for the feedback @bootstraponline, we’ll definitely keep this in mind! :slight_smile:

1 Like

@bootstraponline an update for the “abort API with status” - the API should be ready soon, so that you’ll be able to abort builds with success (1) and error (2) codes in addition to the default “aborted” (3) code, using the API.

Unfortunately the UI will also have to be tweaked for this a bit, and that most likely won’t be released this week, but if you’re interested just let me know and we can do a beta test. Technically it will work (on an API level) but the web UI will show those builds the same way as any other success/error build, e.g. won’t show the abort reason text; those will come a bit later.

It sounds like I should wait for the UI enhancement to land first. I think it’d be confusing to use without that. Thanks for the update!

1 Like

Makes sense, we’ll try to finish that as well as soon as possible :slight_smile:

I’m interested in a beta test now since I’m migrating new jobs over. If you could send me the details when you have time, that’d be great.

1 Like

Thanks to bitrise, we now have a solution for building only changed code. In the future, the shell script will go away in favor of first class mono repo support.

1 Like

Thanks for sharing @bootstraponline! :wink:

Just one note, this script uses the undocumented new abort endpoint params, but should be safe to use / we don’t expect to change that in the foreseeable future, and should be documented on the devcenter soon :slight_smile:

First of all, thank you guys for this discussion!

So, I have a mono repo with the structure already described:

   app1/
   app2/

As far as I understand the script attached by @bootstraponline could be used if you have multi bitrise projects for the same repo. Is there any way to have one bitrise project with multiple workflows or even better to skip a certain step of the workflow if nothing changed?

@SoHotSoup sure it is possible, via custom scripts. In general the suggestion is that if you have 2 app projects in the repo then add it as 2 separate apps on bitrise.io

Skipping steps is definitely possible if you’d prefer that, but requires scripting. Related docs: https://devcenter.bitrise.io/tips-and-tricks/disable-a-step-by-condition/ - for scripting see the last section / the bottom of the page.

A related discussion with a script & run_if example: How can I use variables stored with envman in the run_if check before a step is run?

@viktorbenei Thank you! I have opted for more bitrise apps already… :slight_smile: I have achieved build skipping by using and modifying script provided by @bootstraponline.

1 Like

I moved the script I’m using to a step :slight_smile:

1 Like

We’d love this feature as well.
Instead of calling api’s wouldn’t it be easier to check the git history itself in a step, and then supporting a skipped build status? Or am I missing something?

1 Like

Instead of calling api’s wouldn’t it be easier to check the git history itself in a step, and then supporting a skipped build status? Or am I missing something?

I’ve been using that approach for a while. There are problems since git clone fails for various reasons. It’s also slow. Every change triggers all the builds and they must perform a full clone.

On buddybuild with native support, these builds aren’t triggered at all. That’s helped dramatically with performance and build stability.

1 Like

Quick update: this feature is scheduled in the current sprint and we’re working on it, should be available in the upcoming weeks. Will update you here once it’s ready! :wink:

2 Likes

I found out AppCenter also adopted a mono repo and used path triggers to improve build efficiency.

1 Like

Hey @bootstraponline,

We’ve released the mono repo support feature as Selective Builds. You can find this option on the Settings page of your application at the Enable Selective Builds section. You just need to toggle the switch and then add your change paths to the list :wink:

Thank you for the feature request again! :slight_smile:

Happy building :muscle:

2 Likes

Please note that this it GitHub.com only right now!

If you’d need it for another git service please create a new #feature-request!

2 Likes

This topic was automatically closed after 14 days. New replies are no longer allowed.