With the recent infra changes, there is now an http authentication request fronting the qa.scratch.drupal.org website. Unfortunately, it's also challenging scratchtestbot for all xmlrpc() communication attempts (and confirmation patch file downloads), which results in 'Failed to request next test: Authorization Required' errors on every cron run (each minute).

Would it be possible to remove this authentication request from the qa.scratch.drupal.org website ... at least for any request coming from scratchtestbot (hosted at scratchtestbot.osuosl.test)?

This is preventing me from validating a fix which would detect the PDO Exception which the testbots have silently missed in every D8 core test for the last 10 days. ;)

CommentFileSizeAuthor
#3 qa.staging.devdrupal.org_.conf_.txt872 bytesdrumm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jthorson’s picture

jthorson CreditAttribution: jthorson commented

Here's the list of paths/files which scratchtestbot will attempt to access. I can work around the xmlrpc.php path with a configuration change, but the patch file downloads are still blocked.

  • /xmlrpc.php
  • /sites/all/modules/project_issue_file_review/server/confirmation/apply.patch
  • /sites/all/modules/project_issue_file_review/server/confirmation/check.patch
  • /sites/all/modules/project_issue_file_review/simpletest/confirmation/pass.patch
  • /sites/all/modules/project_issue_file_review/simpletest/confirmation/fail.patch
  • /sites/all/modules/project_issue_file_review/simpletest/confirmation/review.patch
  • /sites/all/modules/project_issue_file_review/drupal/confirmation/install.patch
  • /sites/all/modules/project_issue_file_review/drupal/confirmation/syntax.patch
  • /sites/all/modules/project_issue_file_review/coder/confirmation/pass.patch
  • /sites/all/modules/project_issue_file_review/coder/confirmation/fail.patch
jthorson’s picture

jthorson CreditAttribution: jthorson commented

Devel and Project_dependency can be removed (but I don't have sufficient permission to actually remove them). That should clear up the verify job.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Title: Authentication Request on qa.scratch.drupal.org breaks dev testbot communications » Get qa.staging.devdrupal.org online
FileSize
qa.staging.devdrupal.org_.conf_.txt872 bytes

Attached is the current vhost for reference. That part seems to be working well.

bzr status still reports

unknown:
  .git/
  .gitignore

Can those be removed or do they need to be kept somehow?

jthorson’s picture

jthorson CreditAttribution: jthorson commented

I removed the git from project_issue_file_review ... wasn't aware the entire site was also a git repo.

Based on the log, however, there's nothing but an initial commit ... so I'm sure the history can be wiped. But it was initialized with root, so I can't do it.

jthorson’s picture

jthorson CreditAttribution: jthorson commented

Ah, shoot ... I messed up the file names above.

Note the extra 'review' directory in the following (most, but not all, of the above):

  • /sites/all/modules/project_issue_file_review/review/simpletest/confirmation/pass.patch
  • /sites/all/modules/project_issue_file_review/review/simpletest/confirmation/fail.patch
  • /sites/all/modules/project_issue_file_review/review/simpletest/confirmation/review.patch
  • /sites/all/modules/project_issue_file_review/review/drupal/confirmation/install.patch
  • /sites/all/modules/project_issue_file_review/review/drupal/confirmation/syntax.patch
  • /sites/all/modules/project_issue_file_review/review/coder/confirmation/pass.patch
  • /sites/all/modules/project_issue_file_review/review/coder/confirmation/fail.patch

So the regex could use an optional 'review/' directory.

^/sites/all/modules/project_issue_file_review/(review)?[^/]*/confirmation/(apply|check|fail|install|pass|review|syntax)\.patch$
drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Active » Fixed

I added a / following review:

SetEnvIf Request_URI "^/sites/all/modules/project_issue_file_review/(review/)?[^/]*/confirmation/(apply|check|fail|install|pass|review|syntax)\.patch$" allow_all

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jthorson’s picture

jthorson CreditAttribution: jthorson commented
Priority: Normal » Major
Status: Closed (fixed) » Active

The fix in #6 appears to be missing again, after the infra changes at the end of May:

'failed to retrieve [check.patch] from [qa.staging.devdrupal.org]'

It's either this, or a certificate problem ... but new 'staging' testbots will not pass their confirmation tests as a result.

jthorson’s picture

jthorson CreditAttribution: jthorson commented

In addition to #8, I need to know the actual IP for stagingwww, to apply the same HTTP 413 workaround that we did for production.

jthorson’s picture

jthorson CreditAttribution: jthorson commented
Issue tags: +testing, +drupal.org D7

This is needed to facilitate Drupal.org D7 testing of PIFT.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Assigned: Unassigned » drumm

I'm working on moving this to nginx configuration, which now does http passwords for staging.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

#6 should be fixed again. https://qa.staging.devdrupal.org/sites/all/modules/project_issue_file_re... does not ask for an http password.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

For #9, there is no load balancer to bypass. Nginx, Varnish, and Apache are all running on the same stagingwww box. (The bypass would be by using whatever port Apache is using internally, but that's firewalled off.) Was that workaround for #2002240: Test results not successfully being retrieved by Drupal.org or something else?

jthorson’s picture

jthorson CreditAttribution: jthorson commented
Status: Active » Fixed

Tested, and looks good to go!

Automatically closed -- issue fixed for 2 weeks with no activity.