Multiple builds for one repo

Build Environment
1

Hi all,

What’s the best way to have multiple builds for the same repo on CircleCI? An iOS build and an OS X build in this instance.

Thanks,

3 Likes
2

Will this solution work for you?

1 Like
3

What exactly would your workflow look like? Would you like to be able to trigger the one or the other build? Or it is fine for you to run both the iOS and the OS X build every time?

If it is fine to run them both, just putting the two build commands in the dependencies and test section should be enough:

dependencies:
  override:
    - ./deps-osx.sh
    - ./deps-ios.sh

test:
  override:
    - ./build-test-osx.sh
    - ./build-test-ios.sh

(The script names are completely random for demonstration purposes.)

If you would need to run only certain parts of the build, this API endpoint allows you to trigger a new build with a certain value set for an environment variable, which you could subsequently base the decision of build commands on:

test:
  override:
    - if [[ ! -z $CIRCLE_OSX_BUILD ]] ; then ./build-test-osx.sh ; fi
    - if [[ ! -z $CIRCLE_IOS_BUILD ]] ; then ./build-test-ios.sh ; fi

Another option would be to have two separate projects, one for iOS and one for OS X, one of which would contain all the code and the other one would only contain a circle.yml file. This config-only build would then pull in the project code during the build with git pull.

Would any of those options work for you?

3 Likes
4

@drazisil I saw circleci-matrix, but hesitant to add a dependency. I feel like CircleCI should support this out of the box.

@alexey I would like to run both builds with every push, so the first solution should work. I’ll give it a try. Thanks!

UPDATE: The first solution worked perfectly, thanks again!

4 Likes
5

:+1: for adding this out of the box. Mapping builds 1:1 to GitHub repos is kinda limiting.

@alexey I have a similar problem, in that I want to trigger multiple builds, but I don’t want them to run them together.

We have an Android app with multiple modules. These modules have unit tests and instrumentation tests. The unit tests run super fast and are very stable. The instrumentation tests run much slower and sometimes time out. In fact, our biggest suite always times out in CircleCI, but runs fine in my local machine.

So, I want different builds so that the instrumentation tests run separate.

From the sound of things, this is not possible at the time?

Any plans to add something like this?

Thanks,
Ralph Pina

3 Likes
6

The only thing I can suggest for that right now is to use our nightly builds feature and only run the long tests if a certain environment variable is set—and skip them otherwise.

1 Like
7

Thanks @alexey. I’ve actually taken a slightly different path to fixing this. We run the unit tests in all our branches, and then run the device tests only in beta and master.

test:
    pre:
        # emulator startup need some minutes that's why start it before first build/test steps for build speed up
        - emulator -avd circleci-android22 -no-audio -no-window:
            background: true
            parallel: true

    override:
        - ./gradlew :docbrown:testDebugUnitTest -PdisablePreDex
        - ./gradlew :evermodels:testDebugUnitTest -PdisablePreDex
        - ./gradlew :evernet:testDebugUnitTest -PdisablePreDex
        - ./gradlew :everstore:testDebugUnitTest -PdisablePreDex
        - ./gradlew :mobile:testStagingDebugUnitTest -PdisablePreDex

        - |
            if [ master == $CIRCLE_BRANCH -o beta == $CIRCLE_BRANCH ]; then
                circle-android wait-for-boot
                sleep 30
                adb shell input keyevent 82
                ./gradlew :everstore:connectedDebugAndroidTest -PdisablePreDex
                ./gradlew :mobile:connectedStagingDebugAndroidTest -PdisablePreDex
            fi
1 Like
8

This is an excellent option as well, thanks for sharing your solution.

1 Like
9

+1 for out of the box.

For example 1 build for Linux and 1 for iOS

1 Like
10

I think this is a key suggestion, and might deserve a doc suggesting it as the preferred solution for multi-platform builds. Other posters seem to feel they need to split their codebase, but this should be much more maintainable.

Note that multi-OS support has multiple use-cases for mobile:

  • Cordova
  • React-Native
  • ‘traditional’ native apps that simply wish to share a repo for iOS and Android, particularly if they rely heavily on shared hybrid (javascript) code
2 Likes
11

+1 for native circle support

My use case is testing multiple versions of software running in docker containers.

Due to the 4GB memory limit of circle builds, I cannot run the tests of multiple version support in one build. The test executes 3 docker containers with memory intensive java processes. I need to be able to have two builds start when a commit to the repo happens.

Are there any solutions for this that do not pull in external dependencies outside of circle?

1 Like
12

+1 for out of the box. I’d like to push slightly different builds to different environments in parallel (i.e. at each commit)

Thanks, Chad

1 Like
13

Does someone have an example of a set-up like this? I’d be very interested in doing it this way, although is there a way to trigger the build when the actual code gets updated?

1 Like
14

Big +1 for this.

Keep the .circle.yml file as the default, but add a .circleci directory where we can place multiple ymls and allow selection in the webUI (or even better a file that dictates which circleci file to run given a branch or other variables).

Use case: Monorepos with lots of services and tests. We want test results ASAP, but don’t need to wait on a docker image build.

1 Like
15

Is this issue/feature being addressed in Circle CI 2.0?

3 Likes
16

+1 for out of the box, important when we have multiple lambda’s and are all in one repo.