Is this in API or in our short link implementation?

In T244062#5842946, @Dvorapa wrote:

Is this in API or in our short link implementation?

This is an API exception.

In T244062#5842953, @Xqt wrote:

In T244062#5842946, @Dvorapa wrote:

Is this in API or in our short link implementation?

This is an API exception.

Yeah, but do we use/provide the correct user? Is this really done under Pywikibot-* account?

https://en.wikipedia.org/wiki/Special:GlobalBlockList?ip=35.222.7.205

https://meta.wikimedia.org/w/index.php?title=Steward_requests%2FGlobal_permissions&type=revision&diff=19767314&oldid=19766748

GIPBE duly granted.

In T244062#5843377, @revi wrote:

GIPBE duly granted.

Great, thanks!

@revi Have you granted the rights for all Travis/AppVeyor IPs? Or just those mentioned in the request? (I don't know, how it works, just better to ask)

Only two accounts (pywikibot-oauth and pywikibot-test) were granted GIPBE, and you must authenticate as one of the accounts to enjoy the IP Block exemption. We are not willing to unblock Amazon Web Services/Google Cloud/Microsoft Azure/etc etc IPs as they are frequently abused for provisioning VPN node to vandalize Wikipedia.

In T244062#5843425, @revi wrote:

Only two accounts (pywikibot-oauth and pywikibot-test) were granted GIPBE, and you must authenticate as one of the accounts to enjoy the IP Block exemption. We are not willing to unblock Amazon Web Services/Google Cloud/Microsoft Azure/etc etc IPs as they are frequently abused for provisioning VPN node to vandalize Wikipedia.

Yeah, I meant if you granted GIPBE correctly as it still seems Pywikibot-test/Pywikibot-oauth are blocked too on some Travis/AppVeyor IP ranges (not all of them, but some of them for sure).

GIPBEs does not exempt you from the local blocks, check if there is local block against that IP on the project you are editing.

I see, thank you!

Currently it fails on enwiki and testwiki.

Change 571695 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [tests] Show additional informations with "urlshortener-blocked" APIError

https://gerrit.wikimedia.org/r/571695

Change 571695 merged by jenkins-bot:
[pywikibot/core@master] [tests] Show additional informations with "urlshortener-blocked" APIError

https://gerrit.wikimedia.org/r/571695

There is a local block too: https://en.wikipedia.org/wiki/Special:BlockList?ip=35.222.7.205

In T244062#5876639, @Xqt wrote:

There is a local block too: https://en.wikipedia.org/wiki/Special:BlockList?ip=35.222.7.205

@Anomie, @Legoktm, @SQL : Can you help in this matter and grant local ipblock exempt for pywikibot-test and pywikibot-oauth at en-wiki please. WP:UTRS does no work in that case for a foreign user.

Change 571730 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [bugfix] userinfo is required for user name or IP no

https://gerrit.wikimedia.org/r/571730

Change 571730 merged by jenkins-bot:
[pywikibot/core@master] [bugfix] userinfo is required for user name or IP no

https://gerrit.wikimedia.org/r/571730

Hm, there is only a global block for the newly given IP but the script account is not logged in:
https://meta.wikimedia.org/wiki/Special:BlockList?wpTarget=67.225.165.198&blockType=&limit=50&wpFormIdentifier=blocklist
https://ci.appveyor.com/project/Ladsgroup/pywikibot-g4xqx/builds/30751187/job/qb01ao6ii9mkalvq

No, site.user() is empty even when logged in. self.site.username() still retrieves Pywikibot-test

$ python pwb.py shell
Welcome to the Pywikibot interactive shell!
>>> s=pywikibot.Site()
>>> s.user()
>>> s.username()
'DvorapaBot'

In T244062#5877523, @Dvorapa wrote:

No, site.user() is empty even when logged in. self.site.username() still retrieves Pywikibot-test

def user(self):
    """Return the currently-logged in bot username, or None."""
    if self.logged_in():
        return self.username()
    else:
        return None

Try site.logged_in()

Then self.logged_in() does not work as expected:

$ python pwb.py login
Logged in on wikipedia:cs as DvorapaBot.
$ python pwb.py shell
Welcome to the Pywikibot interactive shell!
>>> s=pywikibot.Site()
>>> s.logged_in()
False

Does it have something in common with those warnings all over tests:

WARNING: No user is logged in on site wikipedia:en
skipped 'TestUserWatchedPages: Not able to login to wikipedia:en'

?

Perhaps we should solve T137805 first

I guess user attribute must be set forthe test class to force login. After global blocks for several IPs used by test runners the account must be logged in for this api method. Surely without block this test will work I think.

Change 571919 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [bugfix] Force login for TestShortLink

https://gerrit.wikimedia.org/r/571919

Change 571919 merged by jenkins-bot:
[pywikibot/core@master] [bugfix] Force login for TestShortLink

https://gerrit.wikimedia.org/r/571919

Change 585068 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [tests] Use meta for TestShortLink

https://gerrit.wikimedia.org/r/585068

Change 585068 merged by jenkins-bot:
[pywikibot/core@master] [tests] Use meta for TestShortLink

https://gerrit.wikimedia.org/r/585068

Shouldn't we login to meta in the create_shortlink method itself? Rather than workaround it in tests?

It seems it works correctly, but weirdly enough the test fails (failed). There might be some issue with test initiation.

In T244062#6017699, @Dvorapa wrote:

Shouldn't we login to meta in the create_shortlink method itself? Rather than workaround it in tests?

I thought that unified global account are logged in automatically. Seems that isn't here, probably due to login/logout tests or something else. I never saw this failure locally. I think for a logged in bot it works independently of the site. But here in test environment it does not. Probable the test class can be switched to DefaultSiteTestCase but with additional login at meta within setUpClass.

In T244062#6017891, @Dvorapa wrote:

It seems it works correctly, but weirdly enough the test fails (failed). There might be some issue with test initiation.

The only difference is the system site package; no idea what this means for this failing.

In T244062#6017969, @Xqt wrote:

In T244062#6017699, @Dvorapa wrote:

Shouldn't we login to meta in the create_shortlink method itself? Rather than workaround it in tests?

I thought that unified global account are logged in automatically. Seems that isn't here, probably due to login/logout tests or something else. I never saw this failure locally. I think for a logged in bot it works independently of the site. But here in test environment it does not. Probable the test class can be switched to DefaultSiteTestCase but with additional login at meta within setUpClass.

Okay, what if tests are "unified global account are logged in automatically" in the beginning of tests (initiation of Meta Class?), then login_logout test will logout all of them successfully and finally they are logged out here? Perhaps we should try to reinitiate Meta Class/Meta Class'es Site() after login_logout test?

In T244062#6017983, @Dvorapa wrote:

Okay, what if tests are "unified global account are logged in automatically" in the beginning of tests (initiation of Meta Class?), then login_logout test will logout all of them successfully and finally they are logged out here? Perhaps we should try to reinitiate Meta Class after login_logout test?

There is another issue: At Travis we run up to 5 jobs simultaneously. With each logout all current jobs are logged out and need to re-login. Parallel jobs saves test time but it can cause failures. Probably we should run login/logout tests on Appveyor only because the we have only 1 job running at the same time there.

In T244062#6018028, @Xqt wrote:

In T244062#6017983, @Dvorapa wrote:

Okay, what if tests are "unified global account are logged in automatically" in the beginning of tests (initiation of Meta Class?), then login_logout test will logout all of them successfully and finally they are logged out here? Perhaps we should try to reinitiate Meta Class after login_logout test?

There is another issue: At Travis we run up to 5 jobs simultaneously. With each logout all current jobs are logged out and need to re-login. Parallel jobs saves test time but it can cause failures. Probably we should run login/logout tests on Appveyor only because the we have only 1 job running at the same time there.

Good point. Another option (imo worse) would be to run Travis test the same as AppVeyor. And finally DefaultSiteTestCase could somehow check login status and relogin if it detects there is an issue.

Change 587310 had a related patch set uploaded (by Dvorapa; owner: Dvorapa):
[pywikibot/core@master] [test] Make sure test user is logged in on meta:meta

https://gerrit.wikimedia.org/r/587310

Change 587310 merged by jenkins-bot:
[pywikibot/core@master] [test] Make sure test user is logged in on meta:meta

https://gerrit.wikimedia.org/r/587310