hledger/.travis.yml
2019-03-09 17:13:58 -08:00

225 lines
8.4 KiB
YAML

# 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/
- hledger-api/.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
# - stack build --only-dependencies hledger-api # --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
- stack build --ghc-options=-Werror hledger-api
# 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
#- stack build --ghc-options=-Werror --test --haddock --no-haddock-deps hledger-api
# 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:
irc:
channels:
- "chat.freenode.net#hledger"
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