Fix up Jenkins tests for AUSv2

RESOLVED WONTFIX

Status

P1
normal
RESOLVED WONTFIX
7 years ago
4 years ago

People

(Reporter: nthomas, Assigned: rhelmer)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 574125 [details] [diff] [review]
Local change on jenkins

rhelmer, rail and I were looking at jenkins over the weekend and noticed it wasn't polling CVS for changes. So I configured it to look, and accidentally blew away this local change to tests/Verify.txt. Looks like it's needed to run the fitnesse tests without a timeout.

Should we land this or did you want to change the setup on the new Jenkins to make the settings in CVS valid ?
Attachment #574125 - Flags: review?(rhelmer)
(Assignee)

Comment 1

7 years ago
Comment on attachment 574125 [details] [diff] [review]
Local change on jenkins

Yes this is fallout from the move to the new Jenkins server that I hadn't followed up on yet (I had patched it manually just to test). This looks exactly like what I was thinking of :) Thanks for following up.

Fitnesse can be a real pain to get going, hopefully it will just work when this is checked in.
Attachment #574125 - Flags: review?(rhelmer) → review+
(Reporter)

Comment 2

7 years ago
Woo, I'd fished the diff out of the workspace.

Checking in Verify.txt;
/cvsroot/mozilla/webtools/aus/tests/Verify.txt,v  <--  Verify.txt
new revision: 1.25; previous revision: 1.24
done

Poller picked up the change, which ran green:
  https://hudson.mozilla.org/job/AUSv2/167/
Assignee: morgamic → rhelmer
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Reporter)

Comment 3

7 years ago
rhelmer noticed the result was
 'AusTests, 316 pages: 0 wrong, 316 ignored or with exceptions'

So that's not really green then is it Jenkins!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 4

7 years ago
It boils down to python traceback ending in
  File "/usr/lib64/python2.6/urllib2.py", line 518, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 403: Forbidden
(Assignee)

Comment 5

7 years ago
(In reply to Nick Thomas [:nthomas] from comment #4)
> It boils down to python traceback ending in
>   File "/usr/lib64/python2.6/urllib2.py", line 518, in http_error_default
>     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
> HTTPError: HTTP Error 403: Forbidden

Hmm I think there is a specific vhost on the server it needs to point to instead of "localhost", I may need to get access to the server to diagnose.
(Reporter)

Comment 6

7 years ago
Shyam, can you help us out here ?
I don't see anything special on the older boxes :

[root@sm-hudson01 ~]# httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:82                   is a NameVirtualHost
         default server sm-hudson01.mozilla.org (/etc/httpd/conf/httpd.conf:1022)
         port 82 namevhost sm-hudson01.mozilla.org (/etc/httpd/conf/httpd.conf:1022)
*:81                   is a NameVirtualHost
         default server sm-hudson01.mozilla.org (/etc/httpd/conf/httpd.conf:1016)
         port 81 namevhost sm-hudson01.mozilla.org (/etc/httpd/conf/httpd.conf:1016)
         port 81 namevhost jenkins.mozilla.org (/etc/httpd/conf/domains/hudson.mozilla.org.conf:7)
*:80                   is a NameVirtualHost
         default server sm-hudson01.mozilla.org (/etc/httpd/conf/httpd.conf:996)
         port 80 namevhost sm-hudson01.mozilla.org (/etc/httpd/conf/httpd.conf:996)
         port 80 namevhost jenkins.mozilla.org (/etc/httpd/conf/domains/hudson.mozilla.org.conf:1)

[root@dm-hudson01-slave01 ~]# httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:82                   is a NameVirtualHost
         default server dm-hudson01-slave01.mozilla.org (/etc/httpd/conf/httpd.conf:994)
         port 82 namevhost dm-hudson01-slave01.mozilla.org (/etc/httpd/conf/httpd.conf:994)
I do see this :

# for AUSv2
<VirtualHost _default_:82>
    ServerAdmin webmaster@mozilla.org
    DocumentRoot /var/www/html
    <Directory "/var/www/html">
      AllowOverride All
    </Directory>
</VirtualHost>

And I have :

<VirtualHost localhost:80>
    ServerName localhost
    ServerAdmin webmaster@mozilla.org
    DocumentRoot /var/www/html

    <Directory /var/www/html/>
        AllowOverride All
    </Directory>

</VirtualHost>
(Reporter)

Comment 9

7 years ago
The scripts copy the AUS code into /var/www/html/aus/, and Fitnesse is configured to make requests to 'http://localhost/aus/update'. That looks like it should all work, assuming that there is a RewriteRule something like
 RewriteRule ^/aus/update/(.*)$ aus/index.php?path=$1 [QSA]
I'm adapting that from a different setup so that may not be quite right.

If it's all working then a request to http://localhost/aus/update/2/Synthetic/1.0/1000000001/platform/locale/channel/osVersion///update.xml should return

<?xml version="1.0"?>
<updates>
    <update type="minor" version="1.0" extensionVersion="1.0" buildID="2006010101" detailsURL="http://detail.url/content.html ">
        <patch type="complete" URL="http://synthetic.1.0.platform.buildid.locale.channel/complete001" hashFunction="SHA1" hashValue="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" size="12345"/>
    </update>
</updates>
(Assignee)

Comment 10

7 years ago
Did this ever get fixed? Shyam, did you get a chance to look at comment 9 (I don't think I have access to this box)
(In reply to Robert Helmer [:rhelmer] from comment #10)
> Did this ever get fixed? Shyam, did you get a chance to look at comment 9 (I
> don't think I have access to this box)

Sorry, this fell through the cracks with all the other things happening in December.

This is what I see :

[root@jenkins1.dmz.phx1 inc]# curl http://localhost/aus/update/2/Synthetic/1.0/1000000001/platform/locale/channel/osVersion///update.xml
<?xml version="1.0"?>
<updates>
</updates>

So something is busted?
(Assignee)

Updated

7 years ago
Priority: -- → P1
(Reporter)

Comment 12

7 years ago
We're still seeing results like comment #3 and #4. Any ideas on how to move forward here ? Is this some problem master/slave setup ?
(Reporter)

Comment 13

7 years ago
It would be really great if we could fix this once and for all, but I don't know enough about Jenkins in general or our setup to to suggest more than comment #12.
Assignee: rhelmer → server-ops-devservices
Component: General → Server Operations: Developer Services
Product: AUS → mozilla.org
QA Contact: general → shyam
Version: 3.0 → other
(Assignee)

Comment 14

7 years ago
(In reply to Nick Thomas [:nthomas] from comment #13)
> It would be really great if we could fix this once and for all, but I don't
> know enough about Jenkins in general or our setup to to suggest more than
> comment #12.

Sorry fell off my radar; I can take another look at it this week.
Assignee: server-ops-devservices → rhelmer
(Assignee)

Comment 15

7 years ago
I'll likely need some extra IT help since it seems like everything should work (and works for me locally)
Rob, timeout. Reopen when you need a hand :)
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago6 years ago
Resolution: --- → INCOMPLETE
(Assignee)

Comment 17

6 years ago
Hey now that we have vagrant working on jenkins (bug 703193), we could run it this way instead.. will look into that.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
(Assignee)

Comment 18

4 years ago
This is still busted, Nick and I tend to run these tests manually. Until AUSv2 is dead I think it's worth getting this going again.

Updated

4 years ago
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
(Reporter)

Comment 19

4 years ago
AUS2 has been deprecated for all but release and esr users, and we plan to transition those of the next month or so, so probably not worth fixing this.
(Assignee)

Comment 20

4 years ago
(In reply to Nick Thomas [:nthomas] from comment #19)
> AUS2 has been deprecated for all but release and esr users, and we plan to
> transition those of the next month or so, so probably not worth fixing this.

WFM, we can continue to run it manually in the meantime if needed (probably not even that)
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.