When we run:
py.test -m "some marks" dirsrvtests/
It conflicts with dirsrvtests/create_test.py:
======================================================= ERRORS ======================================================== ___________________________________________ ERROR collecting create_test.py ___________________________________________ dirsrvtests/create_test.py:86: in <module> displayUsage() dirsrvtests/create_test.py:33: in displayUsage exit(1) /usr/lib64/python2.7/site.py:364: in __call__ raise SystemExit(code) E SystemExit: 1 --------------------------------------------------- Captured stdout --------------------------------------------------- Missing required ticket number/suite name Usage: create_ticket.py -t|--ticket <ticket number> -s|--suite <suite name> [ i|--instances <number of standalone instances> [ -m|--masters <number of masters> -h|--hubs <number of hubs> -c|--consumers <number of consumers> ] -o|--outputfile ] If only "-t" is provided then a single standalone instance is created. Or you can create a test suite script using "-s|--suite" instead of using "-t|--ticket".The "-i" option can add mulitple standalone instances(maximum 10). However, you can not mix "-i" with the replication options(-m, -h , -c). There is a maximum of 10 masters, 10 hubs, and 10 consumers. ========================================= 500 tests deselected by "-m 'acl'" ========================================== ================================= 1 passed, 500 deselected, 1 error in 16.06 seconds ==================================
I propose to move dirsrvtests/create_test.py tool to another location. I see three options: 1. To the root of the repo; 2. Create a new dir and place the tool there. For example, tools/create_test.py; 3. Remove the create_test.py from repo and load it somewhere else. Put a link to the file on this web page.
Personally, I prefer the third option. I think, it will make our source repository more consistent.
What do you think, guys? I think, it should be the mutual decision.
create_test.py should be maintained and git repo is the best place to do so. Maintaining it in wiki is a bad idea.
I would place it under cmd/ which is already present.
Replying to [comment:2 vashirov]:
create_test.py should be maintained and git repo is the best place to do so. Maintaining it in wiki is a bad idea. I would place it under cmd/ which is already present.
We can't put it under '''dirsrvtests/cmd/create_test.py''', because it will still brake this command:
{{{ py.test -m "some marks" dirsrvtests/ }}}
But if we don't want to put this script to the upper directory(that is the root dir of our repo) or any other dir(except '''dirsrvtests'''), then we, our customers and contributors have to run our tests only like this:
{{{ py.test -m "some marks" dirsrvtests/tickets/ dirsrvtests/suites/ }}}
As my opinion, it is not really comfortable and users that don't know this "feature" will face it every second time, while try to run '''py.test''' on the whole directory. If we decide to proceed so, we should mention this in our guide.
create_test.py needs to stay in the DS source code.
One option would be to restructure the source under /ds/dirsrvtests:
ds/dirsrvtest/tests -> contains tickets, suites, data, etc. then leave create_test.py in dirsrvtests/
This might cause issues with getDir() in init.py, so this will need to be looked at as well.
Replying to [comment:4 mreynolds]:
Replying to [comment:2 vashirov]: create_test.py should be maintained and git repo is the best place to do so. Maintaining it in wiki is a bad idea. I would place it under cmd/ which is already present. create_test.py needs to stay in the DS source code. One option would be to restructure the source under /ds/dirsrvtests: ds/dirsrvtest/tests -> contains tickets, suites, data, etc. then leave create_test.py in dirsrvtests/ This might cause issues with getDir() in init.py, so this will need to be looked at as well.
I am totally agree with you. I've already started to work on this enhancement and there is plenty of conflicts. So work in progress. :)
attachment 0001-Ticket-48368-Resolve-the-py.test-conflicts-with-the-.patch
Because of the action (moving files), the patch file is enormous. So you can download it and after that apply it to repo.
Looks good, ack.
To ssh://git.fedorahosted.org/git/389/ds.git 797786d..d89efda master -> master commit d89efda Author: Simon Pichugin spichugi@redhat.com Date: Fri Mar 4 17:09:21 2016 +0100
For next branches, patches were created manually, because its dirsrvtests structure differs very much from master: 50405f8..766bcd1 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 766bcd1 Author: Simon Pichugin spichugi@redhat.com Date: Fri Mar 4 18:18:28 2016 +0100
17bb068..8081159 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 8081159 Author: Simon Pichugin spichugi@redhat.com Date: Fri Mar 4 18:23:06 2016 +0100
Metadata Update from @mreynolds: - Issue assigned to spichugi - Issue set to the milestone: lib389 1.0.2
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1699
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.