URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: opened
PR body: """ sssd-testlib: library containing shared functions to automtate sssd using pytest
copr: https://copr.fedorainfracloud.org/coprs/mrniranjan/sssd-testlib/
Signed-off-by: Niranjan M.R mrniranjan@redhat.com """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
centos-ci commented: """ Can one of the admins verify this patch? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-275849856
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
centos-ci commented: """ Can one of the admins verify this patch? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-275849857
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ ok to test """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-275914396
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-276301606
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
lslebodn commented: """ There are some trailing white spaces ``` sh$ ABS_TOP_SRCDIR=$PWD src/tests/whitespace_test Trailing whitespace found: src/tests/python/README.rst:4:`sssd.testlib`_ is a library containing shared functions to automtate `System Services Security Daemon __` using pytest framework. ```
and pep8 warnings. We try to follow pep8 for new python code ``` sh$ find src/tests/python/ -name "*.py" | xargs pep8 | wc -l 249 ``` """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-276899501
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277002496
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
lslebodn commented: """ On (02/02/17 08:14), Jakub Hrozek wrote:
On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
May I know why git submodule is better?
The idea is that all test will pass with upstream so upstream distributions should use the version from tarball (+ patches)
Or could you describe your use-case why git-submodule is better?
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277007013
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ On Thu, Feb 02, 2017 at 08:29:15AM -0800, lslebodn wrote:
On (02/02/17 08:14), Jakub Hrozek wrote:
On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
May I know why git submodule is better?
The idea is that all test will pass with upstream so upstream distributions should use the version from tarball (+ patches)
Or could you describe your use-case why git-submodule is better?
I was under the impression that the tests should also be usable by downstream. The submodule would make it possible to git clone just the tests w/o the rest of sssd.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277008377
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
lslebodn commented: """ On (02/02/17 08:33), Jakub Hrozek wrote:
On Thu, Feb 02, 2017 at 08:29:15AM -0800, lslebodn wrote:
On (02/02/17 08:14), Jakub Hrozek wrote:
On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
May I know why git submodule is better?
The idea is that all test will pass with upstream so upstream distributions should use the version from tarball (+ patches)
Or could you describe your use-case why git-submodule is better?
I was under the impression that the tests should also be usable by downstream. The submodule would make it possible to git clone just the tests w/o the rest of sssd.
And how will you know which git hash from "submodule repo" should be used for testing specific version of sssd in downstream ?
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277078660
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ On Thu, Feb 02, 2017 at 12:48:11PM -0800, lslebodn wrote:
On (02/02/17 08:33), Jakub Hrozek wrote:
On Thu, Feb 02, 2017 at 08:29:15AM -0800, lslebodn wrote:
On (02/02/17 08:14), Jakub Hrozek wrote:
On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
May I know why git submodule is better?
The idea is that all test will pass with upstream so upstream distributions should use the version from tarball (+ patches)
Or could you describe your use-case why git-submodule is better?
I was under the impression that the tests should also be usable by downstream. The submodule would make it possible to git clone just the tests w/o the rest of sssd.
And how will you know which git hash from "submodule repo" should be used for testing specific version of sssd in downstream ?
I already keep the rhel- branches in my tree, I was thinking we might expose them on some internal git server and collaborate there.
This is the problem I am thinking about -- the tests might need patching when we add some patch to the 'downstream git branch' or we might just add a test for a bug we fix in the downstream branch.
On the other hand, the developers that mostly work on the tests (the current QE team) might be adding test cases on their own.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277193337
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ I will submit the changes (i.e fixing the pep8 and pylint errors), I am awaiting the changes to be merged downstream first. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277896057
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
lslebodn commented: """ On (03/02/17 00:39), Jakub Hrozek wrote:
On Thu, Feb 02, 2017 at 12:48:11PM -0800, lslebodn wrote:
On (02/02/17 08:33), Jakub Hrozek wrote:
On Thu, Feb 02, 2017 at 08:29:15AM -0800, lslebodn wrote:
On (02/02/17 08:14), Jakub Hrozek wrote:
On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
Looking at the patches I see this can be a completely new library instead of being part of SSSD. Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group).
I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
May I know why git submodule is better?
The idea is that all test will pass with upstream so upstream distributions should use the version from tarball (+ patches)
Or could you describe your use-case why git-submodule is better?
I was under the impression that the tests should also be usable by downstream. The submodule would make it possible to git clone just the tests w/o the rest of sssd.
And how will you know which git hash from "submodule repo" should be used for testing specific version of sssd in downstream ?
I already keep the rhel- branches in my tree, I was thinking we might expose them on some internal git server and collaborate there.
The intention of the effort is upstream first testing. So the test need to pass in upstream first. Could you explain how git submodule is related to "rhel- branches"? I cannot see any benefit. You will need to have the same branches n main repo and also in submodule repo.
This is the problem I am thinking about -- the tests might need patching when we add some patch to the 'downstream git branch'
Could you explain why it would require patching? It would be backported from upstream; the same as fix itself.
or we might just add a test for a bug we fix in the downstream branch.
IMHO, Upstream first == fix will be backported with test. But maybe it's just my naive idea.
On the other hand, the developers that mostly work on the tests (the current QE team) might be adding test cases on their own.
But I see a problem here; upstream will fix patches also in stable branches but an author of tests will not be aware of such think They will not know where it should be backported. So stable branches needn't have code coverage.
And I cannot see a problem why members of QE could not have rights to push. We might ask how it is solved in 389ds. Becasue IIRC QEs have right to push patches.
Summary: maybe I am still missing something but I cannot see any benefit of using git submodule.
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277936874
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ On Tue, Feb 07, 2017 at 12:50:23AM -0800, lslebodn wrote:
On (03/02/17 00:39), Jakub Hrozek wrote:
On Thu, Feb 02, 2017 at 12:48:11PM -0800, lslebodn wrote:
On (02/02/17 08:33), Jakub Hrozek wrote:
On Thu, Feb 02, 2017 at 08:29:15AM -0800, lslebodn wrote:
On (02/02/17 08:14), Jakub Hrozek wrote:
On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote: > Looking at the patches I see this can be a completely new library instead of being part of SSSD. > Knowing this it does make sense to have it as a submodule or even a completely external library (but still under SSSD group). > > I'd like to know the opinion of the more experienced developers about this.
I also like the idea of a git submodule, because IIRC these tests are supposed to be used kind of separately by downstream.
May I know why git submodule is better?
The idea is that all test will pass with upstream so upstream distributions should use the version from tarball (+ patches)
Or could you describe your use-case why git-submodule is better?
I was under the impression that the tests should also be usable by downstream. The submodule would make it possible to git clone just the tests w/o the rest of sssd.
And how will you know which git hash from "submodule repo" should be used for testing specific version of sssd in downstream ?
I already keep the rhel- branches in my tree, I was thinking we might expose them on some internal git server and collaborate there.
The intention of the effort is upstream first testing. So the test need to pass in upstream first. Could you explain how git submodule is related to "rhel- branches"? I cannot see any benefit. You will need to have the same branches n main repo and also in submodule repo.
This is the problem I am thinking about -- the tests might need patching when we add some patch to the 'downstream git branch'
Could you explain why it would require patching? It would be backported from upstream; the same as fix itself.
or we might just add a test for a bug we fix in the downstream branch.
IMHO, Upstream first == fix will be backported with test. But maybe it's just my naive idea.
On the other hand, the developers that mostly work on the tests (the current QE team) might be adding test cases on their own.
But I see a problem here; upstream will fix patches also in stable branches but an author of tests will not be aware of such think They will not know where it should be backported. So stable branches needn't have code coverage.
And I cannot see a problem why members of QE could not have rights to push. We might ask how it is solved in 389ds. Becasue IIRC QEs have right to push patches.
Summary: maybe I am still missing something but I cannot see any benefit of using git submodule.
The question if this would be a benefit is mostly for the downstream folks. I would prefer to let them answer how they want to consume (if in any way at all) the upstream reposiroty.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-277970239
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ This whole effort is to write test cases for features upstream and pull it downstream . And the upstream builds are tested against the testcases written in upstream as well as downstream to check if there are any regressions.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-278367428
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ @mrniranjan @lslebodn it seems that this patch set got a bit stuck. Are the major issues the pep8 warnings and the whitespace issues? If yes, can @mrniranjan respin the patch so that we move forward? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-281293591
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ @lslebodn @jhrozek i have an internal fix for pep8 and whitespaces, and also a lot of pylint fixes are pending internal review. i will try to send a revised patch by this week. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-281675002
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ I have updated the PR with pep8,pylint fixes, please have a look and let me know how we can move forward """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-283878215
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ @lslebodn @jhrozek you can have a look at the documentation of sssd-testlib at https://mrniranjan.fedorapeople.org/sssd-docs/ """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-284141199
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ Any update on this ? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-288003254
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
lslebodn commented: """ On (21/03/17 01:02), Niranjan Mallapadi wrote:
Any update on this ?
It's on my TODO list. But unfortunatelly downstream has higher priority ATM.
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-288012784
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ Any update on this ? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-297654800
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ @lslebodn @jhrozek can you have a look at this initial revision, """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-311862636
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ @lslebodn @jhrozek any update on this. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-322831295
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
lslebodn commented: """ I'll check it next week. I didn't expect so many downstream bug reports :-( """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-322976518
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ @lslebodn @fidencio any update on this. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-343939581
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ @mrniranjan, no updates on this at all.
Although it's on top of my TODO list, downstream work has been prioritized (sorry about that). """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-343948144
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ So, just by running pep8 in the python files I've seen: ``` [ffidenci@pessoa sssd]$ pep8 src/tests/multihost/basic/conftest.py src/tests/multihost/basic/test_basic.py src/tests/python/docs/conf.py src/tests/python/setup.py src/tests/python/sssd/__init__.py src/tests/python/sssd/testlib/__init__.py src/tests/python/sssd/testlib/common/__init__.py src/tests/python/sssd/testlib/common/authconfig.py src/tests/python/sssd/testlib/common/exceptions.py src/tests/python/sssd/testlib/common/libdirsrv.py src/tests/python/sssd/testlib/common/libkrb5.py src/tests/python/sssd/testlib/common/qe_class.py src/tests/python/sssd/testlib/common/utils.py src/tests/multihost/basic/conftest.py:28:1: E302 expected 2 blank lines, found 1 src/tests/multihost/basic/conftest.py:48:1: E302 expected 2 blank lines, found 1 src/tests/multihost/basic/conftest.py:59:1: E302 expected 2 blank lines, found 1 src/tests/multihost/basic/conftest.py:68:1: E302 expected 2 blank lines, found 1 src/tests/multihost/basic/conftest.py:79:1: E302 expected 2 blank lines, found 1 src/tests/multihost/basic/conftest.py:113:80: E501 line too long (89 > 79 characters) src/tests/multihost/basic/conftest.py:129:80: E501 line too long (82 > 79 characters) src/tests/multihost/basic/conftest.py:130:80: E501 line too long (82 > 79 characters) src/tests/multihost/basic/test_basic.py:29:80: E501 line too long (82 > 79 characters) src/tests/multihost/basic/test_basic.py:60:80: E501 line too long (87 > 79 characters) src/tests/multihost/basic/test_basic.py:66:80: E501 line too long (84 > 79 characters) src/tests/multihost/basic/test_basic.py:73:80: E501 line too long (87 > 79 characters) src/tests/multihost/basic/test_basic.py:83:80: E501 line too long (85 > 79 characters) src/tests/python/docs/conf.py:22:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:27:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:32:1: E302 expected 2 blank lines, found 1 src/tests/python/docs/conf.py:37:1: E302 expected 2 blank lines, found 1 src/tests/python/docs/conf.py:40:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:46:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:68:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:96:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:98:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:106:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:109:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:113:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:117:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:123:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:126:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:136:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:137:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:143:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:146:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:150:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:153:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:157:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:162:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:172:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:176:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:180:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:183:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:187:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:190:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:193:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:196:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:199:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:202:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:205:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:210:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:213:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:219:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:223:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:227:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:235:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:236:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:236:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:238:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:239:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:239:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:241:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:242:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:242:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:244:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:245:1: E122 continuation line missing indentation or outdented src/tests/python/docs/conf.py:245:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:258:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:262:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:265:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:268:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:271:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:274:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:281:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:284:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:287:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:302:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:305:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:308:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:311:1: E265 block comment should start with '# ' src/tests/python/docs/conf.py:314:1: W391 blank line at end of file src/tests/python/setup.py:18:13: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:18:15: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:19:16: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:19:18: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:20:20: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:20:22: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:21:25: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:21:27: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:22:15: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:22:17: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:23:12: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:23:14: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:24:17: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:24:19: E251 unexpected spaces around keyword / parameter equals src/tests/python/setup.py:29:25: E231 missing whitespace after ':' src/tests/python/sssd/testlib/common/authconfig.py:144:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/exceptions.py:28:80: E501 line too long (95 > 79 characters) src/tests/python/sssd/testlib/common/exceptions.py:34:80: E501 line too long (90 > 79 characters) src/tests/python/sssd/testlib/common/exceptions.py:40:80: E501 line too long (89 > 79 characters) src/tests/python/sssd/testlib/common/libdirsrv.py:185:1: E101 indentation contains mixed spaces and tabs src/tests/python/sssd/testlib/common/libdirsrv.py:185:1: W191 indentation contains tabs src/tests/python/sssd/testlib/common/libdirsrv.py:186:1: E101 indentation contains mixed spaces and tabs src/tests/python/sssd/testlib/common/libdirsrv.py:186:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/libdirsrv.py:189:5: E303 too many blank lines (2) src/tests/python/sssd/testlib/common/libdirsrv.py:368:80: E501 line too long (93 > 79 characters) src/tests/python/sssd/testlib/common/libkrb5.py:58:80: E501 line too long (81 > 79 characters) src/tests/python/sssd/testlib/common/libkrb5.py:106:80: E501 line too long (95 > 79 characters) src/tests/python/sssd/testlib/common/libkrb5.py:118:80: E501 line too long (95 > 79 characters) src/tests/python/sssd/testlib/common/libkrb5.py:123:80: E501 line too long (96 > 79 characters) src/tests/python/sssd/testlib/common/libkrb5.py:129:80: E501 line too long (99 > 79 characters) src/tests/python/sssd/testlib/common/libkrb5.py:215:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/qe_class.py:178:80: E501 line too long (82 > 79 characters) src/tests/python/sssd/testlib/common/qe_class.py:209:80: E501 line too long (87 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:104:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:117:80: E501 line too long (85 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:260:80: E501 line too long (95 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:261:80: E501 line too long (101 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:262:1: E101 indentation contains mixed spaces and tabs src/tests/python/sssd/testlib/common/utils.py:262:1: W191 indentation contains tabs src/tests/python/sssd/testlib/common/utils.py:263:1: E101 indentation contains mixed spaces and tabs src/tests/python/sssd/testlib/common/utils.py:272:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:279:80: E501 line too long (86 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:307:80: E501 line too long (82 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:331:80: E501 line too long (88 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:350:80: E501 line too long (82 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:457:80: E501 line too long (81 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:462:80: E501 line too long (85 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:643:80: E501 line too long (81 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:662:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:664:80: E501 line too long (81 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:680:80: E501 line too long (81 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:697:80: E501 line too long (86 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:720:80: E501 line too long (80 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:736:80: E501 line too long (88 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:737:80: E501 line too long (87 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:738:80: E501 line too long (86 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:741:80: E501 line too long (86 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:742:80: E501 line too long (87 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:743:80: E501 line too long (104 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:764:80: E501 line too long (81 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:771:80: E501 line too long (93 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:782:80: E501 line too long (84 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:785:80: E501 line too long (83 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:811:80: E501 line too long (83 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:878:80: E501 line too long (86 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:896:80: E501 line too long (85 > 79 characters) src/tests/python/sssd/testlib/common/utils.py:909:80: E501 line too long (80 > 79 characters) ``` """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-343961498
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ retest this, please """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-343961592
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ whitespace tests failed, please, take a look at: http://vm-031.$%7Babc%7D/logs/job/81/13/summary.html """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-343966523
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ I have fixed most of the errors suggested, i would like if you we don't enforce 80chars limit, the readeability really hampers, Can we have 90 or 100 character limit . """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344156972
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ I am unable to access http://vm-031.$%7babc%7d/logs/job/81/13/summary.html """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344157048
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ I am unable to access the link given """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344157048
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ @mrniranjan, on SSSD we, at least, try enforce 80. You can see by the https://github.com/SSSD/sssd/pull/379.
So, in case we have that PR merged, we'd be officially enforcing 80 chars. But that's something I'll leave for @lslebodn to answer what are his preferences.
About the link, I'm sending you a message in the internal IRC (as there's no private comment on github) """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344157953
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ I've been able to test the patches with some documentation sent by @mrniranjan. As this documentation is related to provisioning downstream infra, it's not worth (nor allowed) to have it published upstream.
The PR works as expected but I'd like to ask for a few changes: - Please, if it makes sense for you, squash https://github.com/fidencio/sssd/commit/6db7bcfd06c36c687f6e7cd7156382676438... into your patch - Please, remove the generated html docs
Once it's done, please, re-submit the PR and let's be sure our internal CI passes and I'll give it my Ack!
Thanks a lot for your work and for your patience! """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344557055
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ Thanks will apply the changes suggested and resend the patch
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344558254
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ Ack! """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344591542
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ With this code being pushed I'd like to ask for: - Add @mrniranjan as SSSD mantainer - Create a pagure session for issues related to this code
@jhrozek, could you do both? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344592012
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ Sure, but I'm not sure what exactly I'm supposed to do :-)
What exact permissions does @mrniranjan need? Does this include push privileges in order to push patches? (IIRC when we were on the phone a couple of weeks ago, we agreed that the tests would be reviewed by people currently working on the test development and not necessarily the "sssd deamon" developers)
What do you mean with pagure session? Account permissions there? Should we also have tags and/or a milestone about the tests? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344728623
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ So, based that the tests would be reviewed by people currently working on the test development, at least in the beginning, I'd like that @mrniranjan could have push access to SSSD in order to avoid their PRs being blocked/waiting for us to push.
Also, I'd like them to have rights to push documentation in our pagure website (so, the docs repo).
And tags would be better than milestones, I guess. Also, a "test" tag on github in order to make easier to distinguish which are the PRs coming for those tests and which are the PRs coming from the "sssd daemon".
Do these suggestions make sense? """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344731917
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ Sure, thanks for the clarification.
About the push privileges, I would just prefer to drop a mail to sssd-devel before granting push privileges to someone who was not previously much involved in the sssd upstream work. Of cource I trust @mrniranjan to not cause any trouble :-) but I still think it would be nice to let people know why are we granting these push privileges. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344751705
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ Till we have some idea on the review process, the directory structure of where tests should be pushed and how to run those tests , i am okay with not having PUSH access.
Also a couple of points i would like to make.
1. This code here has been a team effort and internal SSSD QE have contributed to this framework/code. Though i have pushed this code from my github account, there have been contributions as well from other SSSD QE engineers.
2. With regard to PUSH access and review process, All the SSSD QE Engineers submit their code individually through their github accounts and raise PR's and devel reviews and PUSH . Over a period of time we can review the PUSH access and once we have a decent set of test cases that we are able to run reliably , we can review the push access.
I will discuss this internally on how we can do review before we submit our tests.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344800105
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ OK, I added @mrniranjan to commit group for https://pagure.io/SSSD/docs/
Then I created the tag "tests" in pagure and added @mrniranjan to the main pagure repo with "ticket" privileges.
I also wonder if we should add a new github team where we would initially add @mrniranjan but also anyone else who would be sending PRs for the pytests. One advantage of having a team is that you can @mention the whole team and set granular permissions for the whole team.
"""
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344867446
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
fidencio commented: """ I really like the idea of having the team there. So, +1 from me. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344871272
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
mrniranjan commented: """ +1 from me for team """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-344963921
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ * master: ee1e4c0fa7e8a973ecf16b7535664b8f47fc7e75 """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-346131417
URL: https://github.com/SSSD/sssd/pull/139 Author: mrniranjan Title: #139: Initial revision of sssd pytest framework Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/139/head:pr139 git checkout pr139
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
jhrozek commented: """ OK, I created a team "Test Developers" and added @mrniranjan there.
Please let me know what other people should be added. Also, I'm OK with granting the push rights, just let me know what suits you best. """
See the full comment at https://github.com/SSSD/sssd/pull/139#issuecomment-346132336
URL: https://github.com/SSSD/sssd/pull/139 Title: #139: Initial revision of sssd pytest framework
Label: +Pushed
sssd-devel@lists.fedorahosted.org
-
fidencio -
jhrozek
-
lslebodn
-
mrniranjan