Closed tovrstra closed 6 years ago
After discussion with @matt-chan : it would be better to split of the env section to a separate file, and have the constant part in another file, e.g. .travis-env.yml
and .travis-body.yml
. We can just use a few lines of shell script before doing a commit:
echo "CHANGES WILL BE OVERWRITTEN!!!" > .travis.yml
cat .travis-env.yml .travis-body.yml >> .travis.yml
This can be done before committing any changes to either files. This may even be done with a pre-commit hook.
Ah I hadn't thought of that... Oh well. I wrote a python script for templating the yml file. It works fairly well and the resulting yml is much cleaner. You just need to populate a dictionary. It's in tools/template.py and also tools/.travis.yml.tpl
Done!
There's a possible 4th case from the gbasis code. If we can't use the conda gcc, we'll have to have another .travis.yml. Not sure what the solution there is...
Solved by using {{ compiler ("c") }}
Ideally, we'd have only three different
.travis.yml
files in the organization:These
.travis.yml
files can be made configurable by sourcing shell scripts that set environment variables. At least two such shell scripts should be present:With this setup, we should select three projects (one of each kind) where improvements to the .travis.yml file are tested before they are applied to other projects. For now the following seems to be a good choice:
derivcheck
python-cython-ci-example
qcgrids
(We can always update later. This coiche has to be a tradeoff between speed of testing new ideas and complexity of the project, such that all features of the
.travis.yml
file get tested.)