* KeyError raised when cloud_provider was used twice in mark parametrization.
* Tox isn't working properly for me (collecting 17,000 files; obviously neglecting tox.ini and/or pytest.ini)
- Split out tests and add markers to control where they are run in Travis
- Run each marker on a separate Travis task
- Install pytest-xdist to increase parallelism inside each worker
- Set xdist parallelism to 3
## Description
Fixes#591.
## Rationale
We are currently not testing many combinations, we run Flake8 on the generated project with default options, but that rarely catch any issues.
## Use case(s) / visualization(s)
Catch problems with invalid combinations, for instance, it fails due to Whitenoise breaking flake8 with `django-compressor` because `STATIC_URL` was undefined here:
b91c70d755/%7B%7Bcookiecutter.project_slug%7D%7D/config/settings/production.py (L185)
* Create a test matrix on Travis CI to help testing multiple options
* Change test_docker.sh to fail if any command in it fails
* Run black on the CI with --check option
* Fix formatting of project files using black
* Install black in the docker container
* Exclude migrations in black checks
* Fix Black formatting violations
* Run black on the whole generated project & fix issues
* Add failing test for travis.yml
I see three options to test travis.yml :
1. Testing that the YAML contains relevant value. Least useful and least
reliable, but simplest to implement.
2. Testing that the YAML is valid TravisCI YAML. Unfortunately this is
difficult / impossible. Doing 'travis lint' would succeed, this command
does not check for 'script' key presence and wouldn't be useful for us.
We could use 'travis-build' to verify that the YAML can be converted to
a worker config, but as of now 'travis-build' doesn't work out of the
box.
There is a new tool for validating travis YAML files 'travis-yml', but
as of now it's a ruby-only library and it's still a work in progress.
3. Running Travis CI task based on the generated YAML. This seems the
best approach, however since cookiecutter-django itself uses Travis CI,
that would require running Travis CI from within Travis CI.
Scheduling Travis CI job without a github push still requires a public
github repo, which is something that we can't generate on demand.
Given that I'm opting to use approach 1.
* Adds missing config to generated .travis.yml
The keys added are as follows:
1. 'script'
Required by Travis, cookiecutter-django used to provide it until it has
been removed together with hitch.
I'm assuming hitch has been replaced with pytest, I'm setting pytest as
the new value for the 'script' key.
2. 'install'
Not required by Travis, but necessary in our case; installs test
libraries, mostly pytest.
As of now this points to 'local.txt' requirements file. There used to be
a separate 'test.txt' requirements file but it has been decided to merge
it with 'local.txt', see discussion in
https://github.com/pydanny/cookiecutter-django/pull/1557 .
* Update CONTRIBUTORS.rst
