Configuring Travis-CI for open source iOS projects

Published on June 05, 2013

Configuring Travis-CI for open source iOS projects

    Continuous integration (continuous integration) - development practice, which allows to achieve greater confidence in the stability and correctness of the work of any project. Open source projects are no exception.

    About two months ago, in April 2013, Sauce labs announced iOS / Mac support for the Travis CI server. The service itself has existed for quite some time, and is quite popular in the open-source community due to its support for a large number of languages and ease of use. The service is free for any github user and open repositories. There is already a post on Habréabout the service and its settings for testing Ruby projects, so in this article I would like to talk about the more specific side of the service - setting up automatic build builds of iOS projects on Travis-CI. The main focus of this article will be the CocoaPods + Cedar + Travis CI bundle, however I will try to tell you a little about other things related to the topic.

    So, let's begin.

    We have a github project that has nothing to do with this article, but wants to be related to Travis CI. The project uses CocoaPods, all tests are written using the Cedar framework.

    Step one. Connect github repository


    We go to the service website , log in using the github account. We go into the profile settings , and turn on the repository on which we want to drive builds and tests.

    Step Two Configuring a configuration file


    Most of the configuration is done in the .travis.yml file, which must be put in the root folder of your repository. In the process, travis-lint can be useful , cut a gem that allows you to validate this file for correctness.

    The first step is to set the programming language for which the build will be implemented.

    language: objective-c
    

    The next step is to configure all the necessary gems and dependencies for the project. The following work steps for the Travis worker are:

    • before_install
    • before_script
    • script
    • after_success / after_failure
    • after_script

    The success of any of these commands (except after_success / after_failure and after / acript) is determined by the return value. The standard Linux code 0 means that the build was successful. Everything else is considered a fail. To configure the necessary dependencies, use the before_install step.

    In particular, we will use the ios_sim gem to run tests on the simulator. Conveniently, Travis has a pre-installed Homebrew, so the installation of the gem has the following form

    before_install:
    		- brew install ios_sim

    Let's run a little ahead. It is not enough just to run the build on the simulator, it is also important to get the results of Cedar - tests. The ios_ci gem will help us with this , allowing you to build a project, run it on a simulator, and get test results. We put gem:

    		- gem install ios_ci

    The next configuration step is optional, and is related to the specific folder structure of the selected project. The Xcode project file is not in the root directory of the repository, but in the Example directory. Therefore, we change the current directory to the directory with the project:

    		- cd Example

    The last step of the setup was to install CocoaPods, however, Travis does this automatically if it finds it in the Podfile directory, so that the setup is complete, you can proceed to the assembly.

    Step Three Project Build and Test Launch


    We pass to the script that will directly run our tests. You need to understand that this does not have to be a Sedar script, or a make command. In fact, the only requirement that Travis CI puts forward to the script step is that it should return a value. 0 is success, everything else is fail. Accordingly, you can build the project the way you need it, and you can use any test framework, including the built-in OCUnit.

    One of the requirements of the ios_ci gem is that for it to work correctly, it needs to transfer the project root directory with the sources. For this purpose, we will use one of the Travis environment variables - $ TRAVIS_BUILD_DIR, which contains the root folder of the repository (all available environment variables can be viewed here ).

    The team to build the project and run the tests will look concise enough

    script: 
    	ios_ci cedar --source-root $TRAVIS_BUILD_DIR/Example --workspace DTTableViewManager.xcworkspace --scheme CedarUnitTests --build-path Build/Products

    Thus, the complete .travis.yml file will look like this:

    language: objective-c
    before_install:
        - gem install ios_ci
        - brew install ios-sim
        - cd Example
    script: ios_ci cedar --source-root $TRAVIS_BUILD_DIR/Example --workspace DTTableViewManager.xcworkspace --scheme CedarUnitTests --build-path Build/Products


    Step Four Profit


    All that remains to be done is to commit to one of the branches, and push the changes to github. Travis-CI will automatically schedule the build, and within a minute or two will begin to assemble the project. If everything goes well, the status will turn green; if not, red. At the same time, a message will be sent to the mail about the success or failure of the assembly.

    Extra Travis-CI Buns


    1. Ability to select repository branches for which the build will be launched.

    branches:
    only:
        - master
        - develop
    

    Thus, Travis will collect builds only for commits made in these two branches. Similarly, you can add branches to the blacklist:

    branches:
    except:
        - legacy
        - experimental
    


    2. The ability to automatically launch builds for pull requests. Moreover, the status of the build will be displayed directly in the pull request on the github page.

    image

    3. Badge !

    image

    The badge is nothing more than a link of the following form

    https://travis-ci.org/[YOUR_GITHUB_USERNAME]/[YOUR_PROJECT_NAME].png?branch=master,staging,production
    


    This article only shows the necessary minimum for setting up builds on Travis-CI. The capabilities of this service are much greater, for example, the famous RestKit framework uses Travis not only to build builds and tests, but also to generate documentation using appledoc .

    Thank you for your attention and successful open-source projects!

    References


    1. Not relevant to this article, but a good framework
    2. Travis-CI
    3. Habrostaty about Ruby - testing for Travis-CI
    4. Documentation for the Travis-CI service
    5. CI - gem for testing iOS applications
    6. Travis-lint