Exclude instead of include folders in SelectiveBuild

Hello!

We are developing KMM cross-platform project for Android na iOS in single repository.
We have 2 Bitrise projects and we’d like to use “Selective Builds” in order to avoid ruing CI if changes do not impact certain platform.
Modules (or directories) in our app are either platform specific

  • androidApp
  • iosApp

or contains common modules (reusable on each platform)

  • featureA
  • onboarding
  • payments

If we make a changes in code in common module, we’d to run both android and iOS CI, but if we do changes only in platform specific module - e.g. androidApp we’d to run only android CI.

Selective builds allow include directories triggering CI , so in this example in Android CI we would have

  • androidApp/**
  • featureA/**
  • onboarding/**
  • payments/**
    but this is not flexible solution, because each time we add new common module we need to add new path to bitrise Selective builds.

Much more flexible solution would be to offer negation in pattern matching, so my selective build would look like the following:

  • !iOS*/**

If there is any other way to exclude iOS modules from selective build (besides skipping workflow - which returns failed build) please tell me.

1 Like

This is a great idea thanks for sharing :smiling_face_with_three_hearts:

Hello,

I looked around and I think that you can use the same patterns as the ones described here

https://apidock.com/ruby/File/fnmatch/class

There is no negation but you should be able to negate ios, with [^i][^o][^s]

1 Like

@atanas-bitrise I’ve applied Your in form of following regex
[^ios]*/**
Preliminary it works as expected, so Build run every time changes in any module except the one starting with ios - e.g. iosFeature.

However, I noticed Bitrise Build Github’s Check appears in PR with quite a long delay - about 10 -15 seconds after something new is pushed to repository. Our repository is super small and has only 5 modules in project root, so it shouldn’t take long for Bitris to determinate when fire up workflow

Hi Piotr,

Firstly, I am glad that it worked :slight_smile:

Is the delay happening every time? For example, can we rule out network latency?

Did you see the details of the GitHub webhook? If I am not mistaken, there should be a timestamp. After the GitHub webhook fires, it is transformed to a Bitrise webhook which will start the build.

Was the build delayed or was it just queued and it started later?

Also, could you confirm that you’re not experiencing this delay when you’re not using Selective Builds or when you’re using it with a different pattern?

Best,
Atanas

Atanas I will measure with next PR’s.

1 Like

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