Page MenuHomePhabricator

Upgrade tox on integration slaves
Closed, ResolvedPublic

Description

integration-slave1001 runs tox-1.8.1 while the others run tox-1.7.0, which causes subtle changes in behaviour, which then cause PRs to be OKed or not depending on the host the test runs on.

Ex.

https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose/3005/console

https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose/3006/console

Event Timeline

valhallasw raised the priority of this task from to Needs Triage.
valhallasw updated the task description. (Show Details)
valhallasw subscribed.

Doh, tox is installed by puppet using pip as a provider:

modules/contint/manifests/packages/labs.pp

package { 'tox':
    ensure   => present,
    provider => 'pip',
    require  => Package['python-pip'],
}

Which mean the tox version is whatever was the latest when the instance was created and puppet never attempt to upgrade it. For the Precise instances I end up with:

slave1001 : tox 1.8.1
slave1002 : tox 1.7.0
slave1003 : tox 1.7.1
slave1004 : tox 1.8.0

I am not sure why it would fail with a version of tox and not with another one :-/

In this specific case, because of https://bitbucket.org/hpk42/tox/pull-request/85/fix-command-expansion-and-parsing/diff

Basically, what happened is that the behavior of

variable = a b c
command = nosetests {variable}

changed. Pre-1.7, this meant

nosetests a b c

and this was changed in 1.7 to

nosetests "a b c"

and changed back again in 1.7.2 to

nosetests a b c

So setting versions explicitly in the manifest might be a good idea.

Thanks to have tracked the issue. I remember now I have been hit by that tox regression locally when 1.7 got released but never bothered with it.

I will apply pip install --upgrade tox on all the slaves.

hashar claimed this task.

I have upgraded tox on all Jenkins labs slaves so they now have tox 1.8.1. Thank you!