Django 2.2

[jayvdb]

There is a bit of a special case at the moment with Django 2.2+ , which absolutely needs the xenial image on Travis due to host C libraries.

As a result, the config needs to be a bit more complicated. Here is an example.

https://github.com/barseghyanartur/django-nine/pull/1

It would be nice if there was a tox-travis flag which automatically split any django22 factors onto the xenial images, leaving the others on the (faster, non-sudo) non-xenial job.

[ryanhiebert]

My first thought is that it sounds a bit odd to have something targeted specifically at Django. Perhaps it could be a way to configure list of factors that forced xenial? I'm still fuzzy on what exactly tox-travis should be doing (since we don't do any kind of autoconfiguring for Travis itself) but I'm open to the idea, especially if we don't write it as strictly a Django thing.

It's worth noting that sudo: false images are deprecated and will at some point in the (near?) future be forced to using VMs anyway.

https://blog.travis-ci.com/2018-10-04-combining-linux-infrastructures https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration

The Travis CI Blog: Combining The Linux Infrastructures

The Travis CI Blog: Upcoming Required Linux Infrastructure Migration

[blueyed]

leaving the others on the (faster, non-sudo) non-xenial job.

Is that the case really? From my experience Xenial is as fast as Travis, although it provides sudo automatically.

[jayvdb]

Hmm, I havent done any recent timing comparisons, so only have dated personal experience to go on.

In any case, other motivations for not using the xenial images is nicer to use the travis python: array for the majority of cases, and then add matrix: include: entries only for the new special cases.

1. the syntax for matrix entries is 3x the size of the python array.
2. the existing entries in the python array are known working versions -- asking repos to switch to using xenial for many of their scenarios introduces new unknowns, and they may be reluctant to do it.

I wouldnt expect any Django specific code -- the same problem will occur with other dependencies on the host OS, but it does need to be something that is easy to use.

Perhaps trusty vs xenial can be exposed to the tox.ini [tox-travis] settings somehow.

Or it would be slightly better if they was a way in the tox.ini [tox-travis] settings to say 'py34: everything except for py34-django22' , so they long list of py34 testenvs dont need to be listed. Maybe this is already possible but ive forgotten how.

[rpkilby]

You can set dist: xenial at the top of the config. e.g., https://github.com/encode/django-rest-framework/blob/1c5466eae772212eaf1df1832870cf64b77c9dc5/.travis.yml

GitHub

encode/django-rest-framework

Web APIs for Django. ⚡️. Contribute to encode/django-rest-framework development by creating an account on GitHub.

[jayvdb]

You can set dist: xenial at the top of the config.

I have done that at https://github.com/Styria-Digital/django-rest-framework-jwt/pull/9

The djangorestframework structure is quite nice.

I used [travis:env] TRAVIS=true:codecov to automatically add the codecov factor.

@blueyed , you might want to take a look at that PR -- I ran into a Django 2.2 + pytest-django problem which I couldnt diagnose easily -- I couldnt reproduce it locally. Here is a log of the problem occurring - https://travis-ci.org/jayvdb/django-rest-framework-jwt/jobs/522455505

My branch https://github.com/jayvdb/django-rest-framework-jwt/tree/dj22-matrix and job 6 are the easier place to pick up the problem, where I have removed tox from the situation. Remove the django-admin commands and pytest-django should do the migrations internally, ... but it very verbosely fails repeatedly. Apologies if this is a known problem. I'll try to get a proper bug report sorted out later this week.

Travis CI - Test and Deploy Your Code with Confidence

GitHub

jayvdb/django-rest-framework-jwt

JSON Web Token Authentication support for Django REST Framework - jayvdb/django-rest-framework-jwt

[rpkilby]

@jayvdb. Is using dist: xenial globally sufficient? Or is there a reason it's not?

[jayvdb]

While xenial is the default, many people will have trusty based configs they dont want to change when adding new environments to their matrix. This is especially the case when adding custom source lines for apt packages, which may be unable to replaced easily with xenial ppa:s.

Being able to split a factor across multiple VMs based on another factor is still a bit difficult, requiring the user to write the same thing many times. If the precise/trusty/xenial/etc is exposed as an environment variable, [travis:env] can be used to split the testenvs a bit easier using that variable. I didnt see a variable for that in https://docs.travis-ci.com/user/environment-variables/#default-environment-variables , but it might be an undocumented env var. We could at least document that.

The other aspect is how to invert a selected set of testenvs. Currently it looks like the user needs to write out the opposite set of testenvs. The '!' operator as a prefix for envnames works in tox, but I couldnt get it working with tox-travis.

Environment Variables - Travis CI

[ryanhiebert]

The '!' operator as a prefix for envnames works in tox, but I couldnt get it working with tox-travis.

I didn't know about this, but I'm in favor of matching tox syntax as much as possible.

I'd also be good with adding support for a dist key if we can determine it in a reliable way.

[jayvdb]

Another approach to this is tox's newish TOX_SKIP_ENV, which is effectively a not operator filter on the exploded env list.

I've just used this at https://travis-ci.org/jayvdb/coverage_env_plugin/builds/527603595 , commit https://github.com/jayvdb/coverage_env_plugin/blob/38b723a49bc7eebbd147bc529fcea0d70472ab18/.travis.yml

Travis CI - Test and Deploy Your Code with Confidence

GitHub

jayvdb/coverage_env_plugin

Coverage environment variable plugin. Contribute to jayvdb/coverage_env_plugin development by creating an account on GitHub.