[pgadmin-hackers] Feature test issues
Hi Tira, George, I've just been updating our internal automated test system to run the feature tests, and ran into a couple of additional issues that need to be addressed. Can you look into the following please? - When starting pgAdmin, it's using the default configuration database (CONFIG['SQLITE_PATH']), however for testing we should be using CONFIG['TEST_SQLITE_PATH']). This means that it's polluting the user's default configuration (and if they don't have one, causing an additional initialisation step). - With Python 2.6, the following failure is seen when the first feature test is run: Traceback (most recent call last): File "/var/lib/jenkins/workspace/pgadmin4-master-python26/web/regression/runtests.py", line 286, in verbosity=2).run(suite) File "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/runner.py", line 172, in run test(result) File "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py", line 126, in run test(result) File "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", line 673, in __call__ return self.run(*args, **kwds) File "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", line 633, in run self._feedErrorsToResult(result, outcome.errors) File "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", line 563, in _feedErrorsToResult if issubclass(exc_info[0], self.failureException): TypeError: issubclass() arg 2 must be a class or tuple of classes For completeness, other issues outstanding that we've previously discussed: - pgAdmin processes may remain running after test failures. - The test suite may hang following a feature test failure, at the end of the run. - The screenshot functionality should be fixed (ideally) or removed. - The tests really need to run with a single instantiation of pgAdmin. It's clearly going to be far too slow to start/stop pgAdmin for every test once we start adding more (and moving forward, I really want feature tests to become the default to ensure we're end-to-end testing everything). For reference, each test run (currently one version of Python, against 5 different database servers) is now taking ~5 minutes vs. 1m47s without the feature tests. On the plus side, test runs are now green across the board with feature tests enabled, except for Python 2.6 :-) Thanks! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 commit: Merge the Python 2 & 3 requirements files, and break
Merge the Python 2 & 3 requirements files, and break out test requirements into a separate file. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=1e5de7e66e7e578a7803087389d18102e0f5d945 Modified Files -- Make.bat| 6 +- README | 7 +-- pkg/mac/build.sh| 6 ++ requirements.txt| 39 + requirements_py2.txt| 43 - requirements_py3.txt| 41 --- web/regression/README | 10 ++ web/regression/requirements.txt | 4 8 files changed, 61 insertions(+), 95 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] HEADS-UP: pgAdmin Python requirements changes
I have just committed the following changes to pgAdmin 4. Anyone running automated builds/tests or building packages may need to make changes to their scripts: - requirements_py2.txt and requirements_py3.txt are now merged into a single requirements.txt file. This uses environment specifiers to determine when to install (or not) some version-specific modules. - The modules used purely for regression tests have been removed from requirements.txt, and added to web/regression/requirements.txt. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 commit: Use the correct requirements file when building the P
Use the correct requirements file when building the PIP package, and update the supported Python versions. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=ec0099255a6b4b165667a89c96e6dc8d9d6a6a6a Modified Files -- pkg/pip/setup_pip.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 commit: Remove unused imports.
Remove unused imports. Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=631ddff48534f7e3d8d50203256fdbacb2a90da2 Modified Files -- pkg/pip/setup_pip.py | 2 -- 1 file changed, 2 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 commit: Build a universal Python wheel instead of per-python-
Build a universal Python wheel instead of per-python-version ones. Fixes #2210 Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=074f7a805e64998829b7d3ef94890f9c68743c03 Modified Files -- pkg/pip/build.sh | 2 +- pkg/pip/setup_pip.py | 12 +++- requirements.txt | 3 +++ 3 files changed, 15 insertions(+), 2 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 v1.3 release date
I've tentatively scheduled the 1.3 release for Thursday 9th March, with the tarball being wrapped on Monday 6th March (PM, UK time). Please ensure all work for the next release is completed and committed before then so we have time for regression tests to run! Thanks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 commit: Fix startup complete tests to ensure we properly poll
Fix startup complete tests to ensure we properly poll the server for completed startup. Fixes #2192 Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=2ebd25630760f9f641b9da56f5544e4673e9acad Modified Files -- runtime/pgAdmin4.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Feature test issues
Cool, we already have a task about proper teardown and a couple other things in our backlog. we'll probably get to it in the next day or so. I'll take a look at the other stuff. Also, regarding speed, even without the app startup time, end to end tests are always going to be relatively slow. We definitely want to make sure that the time it takes to run the tests does not grow to where it is a deterrent to running them. There are a variety of things we can do to help address that as our suite grows. For instance, we could consider parallelizing the tests, making setup and teardown more efficient, combining related tests, or even breaking the tests into suites and running only some of them locally by default. Since we only have a couple feature tests so far the speed hasn't really felt like an issue for me yet, but I understand it may be different if you are trying to run in a variety of configurations. Out of curiosity, what is the goal in supporting multiple python versions? Are we working on moving to 3.x and just haven't gotten fully there yet? Tira On Sun, Feb 26, 2017, 3:39 AM Dave Page wrote: > Hi Tira, George, > > I've just been updating our internal automated test system to run the > feature tests, and ran into a couple of additional issues that need to > be addressed. Can you look into the following please? > > - When starting pgAdmin, it's using the default configuration database > (CONFIG['SQLITE_PATH']), however for testing we should be using > CONFIG['TEST_SQLITE_PATH']). This means that it's polluting the user's > default configuration (and if they don't have one, causing an > additional initialisation step). > > - With Python 2.6, the following failure is seen when the first > feature test is run: > > Traceback (most recent call last): > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/web/regression/runtests.py", > line 286, in > verbosity=2).run(suite) > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/runner.py", > line 172, in run > test(result) > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py", > line 87, in __call__ > return self.run(*args, **kwds) > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py", > line 126, in run > test(result) > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", > line 673, in __call__ > return self.run(*args, **kwds) > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", > line 633, in run > self._feedErrorsToResult(result, outcome.errors) > File > "/var/lib/jenkins/workspace/pgadmin4-master-python26/pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", > line 563, in _feedErrorsToResult > if issubclass(exc_info[0], self.failureException): > TypeError: issubclass() arg 2 must be a class or tuple of classes > > For completeness, other issues outstanding that we've previously discussed: > > - pgAdmin processes may remain running after test failures. > > - The test suite may hang following a feature test failure, at the end > of the run. > > - The screenshot functionality should be fixed (ideally) or removed. > > - The tests really need to run with a single instantiation of pgAdmin. > It's clearly going to be far too slow to start/stop pgAdmin for every > test once we start adding more (and moving forward, I really want > feature tests to become the default to ensure we're end-to-end testing > everything). For reference, each test run (currently one version of > Python, against 5 different database servers) is now taking ~5 minutes > vs. 1m47s without the feature tests. > > On the plus side, test runs are now green across the board with > feature tests enabled, except for Python 2.6 :-) > > Thanks! > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [pgadmin-hackers] Feature test issues
On Mon, Feb 27, 2017 at 9:32 AM, Atira Odhner wrote: > Cool, we already have a task about proper teardown and a couple other > things in our backlog. we'll probably get to it in the next day or so. I'll > take a look at the other stuff. > > Also, regarding speed, even without the app startup time, end to end tests > are always going to be relatively slow. We definitely want to make sure > that the time it takes to run the tests does not grow to where it is a > deterrent to running them. > There are a variety of things we can do to help address that as our suite > grows. For instance, we could consider parallelizing the tests, making > setup and teardown more efficient, combining related tests, or even > breaking the tests into suites and running only some of them locally by > default. > Since we only have a couple feature tests so far the speed hasn't really > felt like an issue for me yet, but I understand it may be different if you > are trying to run in a variety of configurations. > > Out of curiosity, what is the goal in supporting multiple python versions? > We support Python 2.6, 2.7, 3.3+. > Are we working on moving to 3.x and just haven't gotten fully there yet? > There is no plan to move to Python 3 only. We do support Python 2.6 too, so that - it works on system like Cento OS 6+ out of box. We (at EnterpriseDB) test pgAdmin 4 with Python 2.6, 2.7, 3.3, 3.4, 3.5 & 3.6. -- Thanks, Ashesh Vashi > Tira > > On Sun, Feb 26, 2017, 3:39 AM Dave Page wrote: > >> Hi Tira, George, >> >> I've just been updating our internal automated test system to run the >> feature tests, and ran into a couple of additional issues that need to >> be addressed. Can you look into the following please? >> >> - When starting pgAdmin, it's using the default configuration database >> (CONFIG['SQLITE_PATH']), however for testing we should be using >> CONFIG['TEST_SQLITE_PATH']). This means that it's polluting the user's >> default configuration (and if they don't have one, causing an >> additional initialisation step). >> >> - With Python 2.6, the following failure is seen when the first >> feature test is run: >> >> Traceback (most recent call last): >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/web/ >> regression/runtests.py", >> line 286, in >> verbosity=2).run(suite) >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/ >> pgadmin-venv/lib/python2.6/site-packages/unittest2/runner.py", >> line 172, in run >> test(result) >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/ >> pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py", >> line 87, in __call__ >> return self.run(*args, **kwds) >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/ >> pgadmin-venv/lib/python2.6/site-packages/unittest2/suite.py", >> line 126, in run >> test(result) >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/ >> pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", >> line 673, in __call__ >> return self.run(*args, **kwds) >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/ >> pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", >> line 633, in run >> self._feedErrorsToResult(result, outcome.errors) >> File "/var/lib/jenkins/workspace/pgadmin4-master-python26/ >> pgadmin-venv/lib/python2.6/site-packages/unittest2/case.py", >> line 563, in _feedErrorsToResult >> if issubclass(exc_info[0], self.failureException): >> TypeError: issubclass() arg 2 must be a class or tuple of classes >> >> For completeness, other issues outstanding that we've previously >> discussed: >> >> - pgAdmin processes may remain running after test failures. >> >> - The test suite may hang following a feature test failure, at the end >> of the run. >> >> - The screenshot functionality should be fixed (ideally) or removed. >> >> - The tests really need to run with a single instantiation of pgAdmin. >> It's clearly going to be far too slow to start/stop pgAdmin for every >> test once we start adding more (and moving forward, I really want >> feature tests to become the default to ensure we're end-to-end testing >> everything). For reference, each test run (currently one version of >> Python, against 5 different database servers) is now taking ~5 minutes >> vs. 1m47s without the feature tests. >> >> On the plus side, test runs are now green across the board with >> feature tests enabled, except for Python 2.6 :-) >> >> Thanks! >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> >
[pgadmin-hackers] help
hi all what is common setting which prevent my db to secure -- [image: http://www.blystreecare.com/images/tree-clipart-4.gif] Save a tree. Please avoid printing this email unless necessary. * Email confidentiality notice * This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
