# https://docs.travis-ci.com/user/customizing-the-build # https://docs.travis-ci.com/user/caching/ # https://docs.travis-ci.com/user/languages/haskell/ # http://docs.haskellstack.org/en/stable/travis_ci.html # https://raw.githubusercontent.com/commercialhaskell/stack/master/doc/travis-simple.yml # https://raw.githubusercontent.com/commercialhaskell/stack/master/doc/travis-complex.yml # https://github.com/hvr/multi-ghc-travis#user-content-travisyml-template-for-non-container-based-infrastructure # https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received # https://github.com/koterpillar/tianbar/blob/master/Dockerfile.base - custom docker image to save time # https://github.com/mapnik/mapnik/blob/master/.travis.yml # # The Build Lifecycle # # A build on Travis CI is made up of two steps: # install: install any dependencies required # script: run the build script # You can run custom commands before the installation step (before_install), and before (before_script) or after (after_script) the script step. # In a before_install step, you can install additional dependencies required by your project such as Ubuntu packages or custom services. # You can perform additional steps when your build succeeds or fails using the after_success (such as building documentation, or deploying to a custom server) or after_failure (such as uploading log files) options. In both after_failure and after_success, you can access the build result using the $TRAVIS_TEST_RESULT environment variable. # The complete build lifecycle, including three optional deployment steps and after checking out the git repository and changing to the repository directory, is: # # OPTIONAL Install apt addons # OPTIONAL Install cache components # before_install # install # before_script # script # OPTIONAL before_cache (for cleaning up cache) # Travis CI uploads the cache after the script phase of the build, but before either after_success or after_failure. # Failure to upload the cache does not mark the job as failed. # after_success or after_failure # OPTIONAL before_deploy # OPTIONAL deploy # OPTIONAL after_deploy # after_script # # we limit the `make` to 40 min # to ensure that slow builds still upload their # cache results and therefore should be faster # (and might work) for the next build # - DURATION=2400 # - scripts/travis-command-wrapper.py -s "date" -i 120 --deadline=$(( $(date +%s) + ${DURATION} )) make sudo: false dist: trusty language: generic cache: timeout: 1000 directories: - $HOME/.stack/ - $HOME/.local/bin/ - .stack-work/ - hledger-lib/.stack-work/ - hledger/.stack-work/ - hledger-ui/.stack-work/ - hledger-web/.stack-work/ # - shelltestrunner/ # addons: # apt: # packages: # - libgmp-dev branches: only: - master # matrix: # include: # - env: ARGS="" # - env: ARGS="--stack-yaml stack-7.10.yaml" # - ghc: 7.10.3 # - ghc: 8.0.2 #before_install: # - ./.travis-maybe-skip.sh # never seemed to work, and can fail, eg: # https://travis-ci.org/simonmichael/hledger/builds/316707766 install: # command output is hidden as they complete # if any command fails, end the travis script - set -e # warn about nulls ? no, breaks travis #- set -u # stack - mkdir -p ~/.local/bin - export PATH=~/.local/bin:$PATH # Fetch latest stack unconditionally. Do this after a stack release or if in doubt. #- travis_retry curl -L https://www.stackage.org/stack/linux-x86_64 | tar xz --wildcards --strip-components=1 -C ~/.local/bin '*/stack'; chmod a+x ~/.local/bin/stack # Or, fetch latest stack if a stack is not already installed. Saves a little time/fragility. - if [[ ! -x ~/.local/bin/stack ]]; then travis_retry curl -L https://www.stackage.org/stack/linux-x86_64 | tar xz --wildcards --strip-components=1 -C ~/.local/bin '*/stack'; chmod a+x ~/.local/bin/stack; fi - which stack - type -a stack - stack --version - echo ~ - ~/.local/bin/stack --version # GHC - stack setup - stack exec -- ghc --version # hledger dependencies, or at least some of them, built separately to use less memory # - stack build --only-dependencies hledger-lib #hledger hledger-ui # --test # TODO does this build hledger-lib & hledger, then rebuild them later with -Werror ? # - stack build cryptohash # - stack build --only-dependencies hledger-web # --test # addon dependencies #- stack build Chart Chart-diagrams colour Diff # shelltestrunner - if [[ ! -x ~/.local/bin/shelltest ]]; then stack install shelltestrunner-1.9; fi - shelltest --version script: # command output is not hidden # less slow # build hledger packages, ensuring no warnings, # and any deps not already cached, separately to use less memory - stack build --ghc-options=-Werror hledger-lib - stack build --ghc-options=-Werror hledger # run hledger-lib/hledger functional tests, skipping the ones for addons - COLUMNS=80 stack exec -- shelltest --execdir -j16 tests -x /bin -x /addons - stack build --ghc-options=-Werror hledger-ui - stack build --ghc-options=-Werror hledger-web # run the built-in hunit tests. This doesn't run the doctests, # but doesn't require rebuilding and is fast #- stack exec -- hledger test # more slow # build hledger packages, ensuring no warnings, no haddock failures, package test suites passing, # and any deps not already cached, separately to use less memory #- stack build --ghc-options=-Werror --test --haddock --no-haddock-deps hledger-lib #- stack build --ghc-options=-Werror --test --haddock --no-haddock-deps hledger #- stack build --ghc-options=-Werror --test --haddock --no-haddock-deps hledger-ui #- stack build --ghc-options=-Werror --test --haddock --no-haddock-deps hledger-web # build hledger addons, ensuring no warnings #- stack build Diff #- stack build Chart #- stack build diagrams-lib #- stack build Chart-diagrams #- sh -e bin/compile.sh # run functional tests #- make functest #after_script: # # # list directory contents # - pwd # - ls -laF / # - ls -laF $HOME # - ls -laF # # # coveralls.io coverage reports # # - stack install hpc-coveralls # # - hpc-coveralls count-von-count-tests --exclude-dir=tests --exclude-dir=src/Gyrid --display-report notifications: # don't need this one, skylink webhook covers it # irc: # channels: # - "chat.freenode.net#hledger-bots" # on_success: change # [always|never|change] default: always # on_failure: change # default: always # use_notice: true # skip_join: true # # If you enable skip_join, remember to remove the NO_EXTERNAL_MSGS flag (n) on the IRC channel(s) the bot notifies. # template: # - "%{commit}: %{message} %{build_url}" # # - "%{repository_name} (%{commit}) : %{message} %{build_url}" # # You can interpolate the following variables: # # repository_slug: your GitHub repo identifier (like svenfuchs/minimal) # # repository_name: the slug without the username # # repository: same as repository_slug [Deprecated] # # build_number: build number # # build_id: build id # # branch: branch build name # # commit: shortened commit SHA # # author: commit author name # # commit_message: commit message of build # # commit_subject: first line of the commit message # # result: result of build # # message: travis message to the build # # duration: duration of the build # # compare_url: commit change view URL # # build_url: URL of the build detail # # The default template is: # # - "%{repository}#%{build_number} (%{branch} - %{commit} : %{author}): %{message}" # # - "Change view : %{compare_url}" # # - "Build details : %{build_url}" # email: # false # recipients: # - one@example.com # - other@example.com # on_success: [always|never|change] # default: change # on_failure: [always|never|change] # default: always webhooks: urls: # travis webhook for skylink irc bot, https://devmode.cloud/docs/webhooks.html#hook-travisci - "https://ingest.devmode.cloud/hooks/travisci?channel=%23hledger-bots&longurl=1" # on_success: change # default: always # on_failure: always # default: always on_start: always # default: never # on_cancel: always # default: always # on_error: always # default: always