What am I doing wrong? "make tests" returns "Ran 0 tests"

Please help me understand this process. :slight_smile:

I want to add a new command-line option*, so I forked and cloned the repo, made the relevant additions and changes on a new branch, and ran “make tests” with hopes of success–this is my first Python code–only to see:

PYTHONPATH=./lib nosetests -d -w test/units -v # Could do: --with-coverage --cover-package=ansible


Ran 0 tests in 0.021s

OK

While no errors were returned, I’m pretty sure running 0 tests confirms nothing.

Oddly, running make tests after checking out the devel branch returns the same thing: Ran 0 tests. (The same results after make clean as well.)

My questions:

-Should I be seeing different results? (or executing a different command?)

-Should I use devel as the base of my new branch?

Any and all help will be appreciated.

Best,

Steven

  • the new option is --force-read, which causes Ansible to read the specified inventory file even when the executable bit is set.

replied earlier, unfortunately didn't cc the list, that a fresh
checkout for me runs 179 tests.

Here's some things to try: what version of nose are you running?
  nosetests --version

Are you on a Linux distribution or something more exotic?

It seems like nosetests isn't finding the unittests. You could try things like:
# Point nose directly at a file containing tests
PYTHONPATH=./lib nosetests -v test/units/TestConstants.py

# Make sure we aren't missing the tests for some strange reason
cd test/units
ls -al

# Run nosetests directly from the testing subdirectory
PYTHONPATH=../../lib nosetests -v

-Toshio

I’m running nosetests 1.3.0 on Debian 6 with Python 2.6.6.

Your first example, specifying TestConstants.py, successfully ran 4 tests and test/units is populated.

Running nosetests -v from within test/units ran 0 tests.

Running PYTHONPATH=./lib nosetests -v test/units/*.py (on devel) runs 126 tests with 60 errors.

Can you see if the last command gives you the same error?

Thank you for your reply.

Best,

-Steven

I can’t get the tests to run, but the functionality works for me locally so I submitted a pull request detailing a frustrating use case.

Submitting a pull request for a bug report seems a bit odd to me - those are for adding new code to the project - can you link to it?

As for this:

“* the new option is --force-read, which causes Ansible to read the specified inventory file even when the executable bit is set.”

I’ll tell you right now that this seems rather opaque and we’re unlikely to include this. Can you share you how you got into this scenario?

The pull request is definitely for new code. See:

https://github.com/ansible/ansible/pull/9463

How I got into this scenario:

I do all of my development on an NTFS-formatted USB drive, which means the executable bits can either for all files can either be set or not–chmod doesn’t work. (At least not on Debian 6.)

My USB drive includes some directories in my PATH, including $GOPATH/bin, so I have to accept all of the files being executable.

I started playing with Vagrant this week to see if it would be useful. It will, particularly with the Ansible provisioner and multi-machine setup, so I tried booting up a few machines and letting Vagrant create the inventory file. It writes out the first machine’s IP, launches Ansible, then Ansible fails with:

ERROR: problem running /mnt/4tb-usb/repos/ansible-playbooks/site/.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory --list ([Errno 8] Exec format error)

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

A small patch to the Ansible provisioner in Vagrant enables support for the --force-read option, allowing Vagrant and Ansible both to work.

The Vagrant scenario excluded, I would rather keep my inventory files on my USB drive. With it being NTFS (so that it also works well with Windows) and requiring every file to retain the executable bit, using Ansible is made more difficult by not offering an option to force reading of the inventory file when the executable bit is set.

Does that help?

Best,

Steven

This is a known mount issue with NTFS, just try adding the following mount options:

umask=0000,fmask=0111

which will turn off the executable bit for files (something that NTFS itself does not really support).

I would if I didn’t need to execute some files on the drive, like those in $GOPATH/bin.

If it helps, a proposed Vagrantfile can be found here:

https://gist.github.com/stephenwithav/27f526c426da5c822a5d

(It works with these minor changes to the Ansible provisioner in Vagrant.)

On the testing front, can we add Travis integration?

I added a .travis.yml for Python 2.6 with script: make test and it, too, ran 0 tests.

Results:

https://travis-ci.org/stephenwithav/ansible

Travis doesn’t really suit the needs of the project much currently, however on another note, you may want to move past trying to run “make tests” and figure out what works for you.

I personally use the following (the -w might be important for you):

nosetests -v -w test/units/ --with-coverage --cover-erase --cover-package=ansible --cover-branch

Thank you for the suggestion, Matt. I tried your test locally and it failed on my machine. I unfortunately don’t know Python well enough to figure out what will work for me.

If Travis isn’t a good fit for Anible, I’ll accept that. I just used it with Vagrant and loved the simple testing it offered, so thought it might be good here.

Best,

-Steven

I’ll be on ansible later if anyone wants to continue this discussion there. (I’m idling in there now.)

My nick is the same as my github one: stephenwithav.

Yeah official conversation needs to happen here vs IRC.

All being said, I’ve replied on the ticket.

I think what needs to happen (see ticket) is that the vagrant plugin, if people are going to be using it on NTFS filesystems, etc, is that it needs to generate a static rather than dynamic inventory.

Vagrant’s Ansible provisioner plugin does, in fact, generate a static inventory with no shebang line.

e.g.:

https://gist.github.com/stephenwithav/92bc5d6faed347865fff

From your comment on the pull request, --force-read really means --interpret-as-static-even-if-chmod-plus-x, not --interpret-as-script-even-if-no-chmod-plus-x. Apologies if my use-case left that unclear.

Thank you for considering this request. I’m using the changes locally (both to Ansible and to the Vagrant plugin) and they are a life saver.

Best,

Steven