未加星标

Eight knobs to adjust and improve your Travis CI builds - Raphael Stolt

字体大小 | |
[开发(php) 所属分类 开发(php) | 发布者 店小二04 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

After having refactored several Travis CI configuration files over the last weeks, this post will provide eight adjustments or patterns immediately applicable for faster, changeable, and economic builds.

1. Reduce git clone depth

The first one is a simple configuration addition with a positive impact on the time and disk space consumption, which should be quite noticeable on larger code bases. Having this configured will enable shallow clones of the Git repository and reduce the clone depth from 50 to 2.

.travis.yml

git: depth: 2 2. Enable caching

The second one is also a simple configuration addition for caching the Composer dependencies of the system under build (SUB) or its result of static code analysis. Generally have a look if your used tools allow caching and if so cache away. This one deserves a shout out to @localheinz for teaching me about this one.

The next shown configuration excerpt assumes that you lint coding standard compliance with thephp Coding Standards Fixer in version 2.0.0-alpha and have enable caching in its .php_cs configuration.

.travis.yml

cache: directories: - $HOME/.composer/cache - $HOME/.php-cs-fixer 3. Enforce contribution standards

This one might be a tad controversial, but after having had the joys of merging GitHub pull requests from a master branch I started to fail builds not coming from feature or topic branch with the next shown bash script. It's residing in an external bash script to avoid the risk of terminating the build process.

./bin/travis/fail-non-feature-topic-branch-pull-request

#!/bin/bash set -e if [[ $TRAVIS_PULL_REQUEST_BRANCH = master ]]; then echo "Please open pull request from a feature / topic branch."; exit 1; fi

.travis.yml

script: - ./bin/travis/fail-non-feature-topic-branch-pull-request The bash script could be extended to fail pull requests not following a branch naming scheme, e.g. feature- for feature additions or fix- for bug fixes, by evaluating the branch name. If this is a requirement for your builds you should also look into the blocklisting branches

feature of Travis CI.

4. Configure PHP versions in an include

With configuring the PHP versions to build against in a matrix include it's much easier to inject enviroment variables and therewith configure the version specific build steps. You can even set multiple enviroment variables like done on the 7.1 version.

.travis.yml

env: global: - disable-xdebug=true - lint=false matrix: include: - php: hhvm env: disable-xdebug=false - php: nightly env: disable-xdebug=false - php: 7.1 env: disable-xdebug=false lint=true - php: 7.0 - php: 5.6 before_script: - if [[ $disable-xdebug = true ]]; then phpenv config-rm xdebug.ini; fi

I don't know if enviroment variable injection is also possible with the minimalistic way to define the PHP versions list, so you should take that adjustment with a grain of salt.

It also seems like I stumbled upon a Travis CI bug , so add another grain of salt. To work around that possible bug the relevant configuration has to look like this, which sadly adds a lot of duplication and might be unsuitable when dealing with a large amount of environment variables.

.travis.yml

matrix: include: - php: hhvm env: disable-xdebug=false lint=false - php: nightly env: disable-xdebug=false lint=false - php: 7.1 env: disable-xdebug=false lint=true - php: 7.0 env: disable-xdebug=true lint=false - php: 5.6 env: disable-xdebug=true lint=false before_script: - if [[ $disable-xdebug = true ]]; then phpenv config-rm xdebug.ini; fi 5. Only do static code analysis or code coverage measurement once

This one is for reducing the build duration and load by avoiding unnecessary build step repetition. It's achived by linting against coding standard violations or generating the code coverage for just a single PHP version per build, in most cases it will be the same for 5.6 or 7.1.

.travis.yml

matrix: include: - php: hhvm env: disable-xdebug=false lint=false - php: nightly env: disable-xdebug=false lint=false - php: 7.1 env: disable-xdebug=false lint=true - php: 7.0 env: disable-xdebug=true lint=false - php: 5.6 env: disable-xdebug=true lint=false script: - if [[ $lint=true ]]; then composer cs-lint; composer test-test-with-coverage; fi 6. Only do release releated analysis and checks on tagged builds

This one is also for reducing the build duration and load by targeting the analysis and checks on tagged release builds. For example if you want to ensure that your CLI binary version, the one produced via the --version option, matches the Git repository version tag run this check only on tagged builds.

.travis.yml

script: - if [[ ! -z "$TRAVIS_TAG" ]]; then composer application-version-guard; fi 7. Run integration tests on very xth build

For catching breaking changes in interfaces or API's beyond your control it makes sense do run integration tests against them once in a while, but not on every single build, like shown in the next Travis CI configuration excerpt which runs the integration tests on every 50th build.

.travis.yml

script: - if [[ $(( $TRAVIS_BUILD_NUMBER % 50 )) = 0 ]]; then composer test-all; else composer test; fi 8. Utilise Composer scripts

The last one is all about improving the readability of the Travis CI configuration by extracting command configurations i.e. options into dedicated Composer scripts . This way the commands are also available during your development activitives and not hidden away in the .travis.yml file.

composer.json

{ "__comment": "omitted other configuration", "scripts": { "test": "phpunit", "test-with-coverage": "phpunit --coverage-html coverage-reports", "cs-fix": "php-cs-fixer fix . -vv || true", "cs-lint": "php-cs-fixer fix --diff --verbose --dry-run" } }

To ensure you don't end up with an invalid Travis CI configuration, which might be accidently committed, you can use composer-travis-lint a simple Composer script linting the .travis.yml with the help of the Travis CI API .

Happy refactoring.

本文开发(php)相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师

主题: PHPGitGitHubUBSU
分页:12
转载请注明
本文标题:Eight knobs to adjust and improve your Travis CI builds - Raphael Stolt
本站链接:http://www.codesec.net/view/481686.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 开发(php) | 评论(0) | 阅读(33)