Debug early tox failures

[fnordahl]

As recorded in #154 we have an intermittent failure at the very
beginning of a tox run which we don't have any visibility into.

Increase verbosity so that we get a chance to catch what's going
on.

[fnordahl]

Converting to draft as I do not know how this would interfere with the fact that we use tox_extra_args to pass in posargs to the func-target env.

[wolsen]

Does this cause problems with future functional tests which also pass arguments such as focal-xena to indicate which test to run?

[ChrisMacNaughton]

I suspect that this change would be "safe", in that it wouldn't break the existing tests; however, I also am fairly sure that it wouldn't have any effect because the latter job overwrites the tox_extra_args value

[fnordahl]

I suspect that this change would be "safe", in that it wouldn't break the existing tests; however, I also am fairly sure that it wouldn't have any effect because the latter job overwrites the tox_extra_args value

@ChrisMacNaughton Right, so a descendant job overwrites parent variables. Do you know where the Emit tox command job is defined, and could that be a place to inject the arguments in the right order without messing with the other arguments?

[ChrisMacNaughton]

The whole tox command comes from zuul-jobs

[fnordahl]

Can it be overridden?

[ajkavanagh]

Can it be overridden?

Yup, all the bits can be overridden; you just mention them in the job. I think the issue is that a job like "focal-ussuri" will override anything you put in the base func-target job in zuul-config. You can create a job in the charm's osci.yaml directly (and remove the other jobs) as a test, with as much extra detail as you want. Which charm/review/job, and I can help out by updating the review.

[fnordahl]

Thanks Alex, trying it out in the per charm job file is a good idea. I'll pop a - name: Emit tox command into one and see what happens.