Closed
Bug 647068
Opened 13 years ago
Closed 13 years ago
Point the automated blocklist update lander to the AMO staging server
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ehsan.akhgari, Assigned: coop)
Details
(Whiteboard: [automation])
Attachments
(1 file)
2.60 KB,
patch
|
bear
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
Based on the discussion that we had with fligtar, RelEng should point the automated blocklist update lander bot to AMO's staging server for blocklist updates.
Assignee | ||
Comment 1•13 years ago
|
||
So what's the URL we should be pointing at? This is the URL we are currently using: http://hg.mozilla.org/build/tools/file/111bf8895346/scripts/blocklist/sync-hg-blocklist.sh#l80
Assignee: nobody → coop
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Whiteboard: [automation]
Looks like https://addons.allizom.org/blocklist/3/${APP_ID}/${VERSION}/${APP_NAME}/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/ based on instructions from https://wiki.mozilla.org/Blocklisting/Testing. (Not sure if the date should be hardcoded in there ...) Fligtar can confirm that. Btw, thanks for filing this bug Ehsan, kinda dropped off my radar.
Comment 3•13 years ago
|
||
Replacing addons.mozilla.org with addons-next.allizom.org should do the trick. (addons-next is more stable than allizom code-wise but uses the same database) Just want to confirm that if the script doesn't get a 200 response nothing really bad is going to happen, right? As it is our staging server, it is down occasionally and other times (like today) we do database imports from production that can take hours.
Assignee | ||
Updated•13 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Assignee | ||
Comment 4•13 years ago
|
||
Attachment #528682 -
Flags: review?(bear)
Updated•13 years ago
|
Attachment #528682 -
Flags: review?(bear) → review+
Comment 5•13 years ago
|
||
Looks like you're using addons.allizom instead of addons-next.allizom. As I mentioned in comment #3, that will work, but -next is going to be more stable.
Assignee | ||
Comment 6•13 years ago
|
||
Comment on attachment 528682 [details] [diff] [review] Switch AMO blocklist URL to allizom, verify XML headers on retrieved files (In reply to comment #5) > Looks like you're using addons.allizom instead of addons-next.allizom. As I > mentioned in comment #3, that will work, but -next is going to be more stable. Re-tested before landing, and then landed with addons-next.allizom.org: http://hg.mozilla.org/build/tools/rev/f1238a6321f3
Attachment #528682 -
Flags: checked-in+
Assignee | ||
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 7•13 years ago
|
||
The blocklist updater that just ran on pm03 for mozilla-central still hit addons.m.o: https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/6.0a1/Firefox/20090105024647/blocklist-sync/en-US/nightly/blocklist-sync/default/default/ Additionally, it removed quite a few entries: http://hg.mozilla.org/mozilla-central/rev/b430e631d5cd This seems to be a genuine difference between staging and production amo. Is that expected fligtar ? The blocklist we're landing in the tree ends up in new users hands for their first run, and some time later they get the prod data. So that kinda requires the amo staging db not get out of sync with prod. How did we get to pointing at staging instead of prod ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 8•13 years ago
|
||
Querying prod again because of this backout: http://hg.mozilla.org/build/tools/rev/af245a1f1eab Comment - revert AMO blocklist URL to pull from live - r=bustage
Assignee | ||
Comment 9•13 years ago
|
||
OK, so this discussion should have happened in the bug, but transpired by email instead.
The last message was from Mossop:
> Justin mentioned to me that they sometimes block Flash in staging so they
> can do testing. I don't think we want that shipping in even nightly builds
> so I think until we're sure of the kinks in the system we should just go
> the safer route and only pull from live for now.
If we figure out a stable way to update from staging, we will revisit this.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•