Version of PSL at publicsuffix.org not refreshing
Categories
(Infrastructure & Operations :: SRE, task)
Tracking
(Not tracked)
People
(Reporter: ryan.sleevi, Assigned: gozer)
Details
This appears to be a repeat of Bug 1515909
The copy of the PSL at publicsuffix.org appears to be stalling out. Downstream, we had this reported as https://github.com/publicsuffix/list/issues/833 which shows which commits are included and which are excluded.
Comment 1•7 years ago
|
||
We fixed this issue, as to why its not updating we will continue to investigate why its not updating via CI
Comment 2•7 years ago
|
||
We just received another report.
https://github.com/publicsuffix/list/issues/852
Comment 3•6 years ago
|
||
There appears to be an intermittent bug in updating the s3 bucket. Logs show everything succeeding so it's not clear where the issue is exactly at this time. We will continue to investigate or create a workaround (probably with a new build pipeline). At this time, we manually re-triggered the job and it built fine, the list is now updated.
Updated•6 years ago
|
Updated•6 years ago
|
| Assignee | ||
Updated•6 years ago
|
| Assignee | ||
Updated•6 years ago
|
| Reporter | ||
Comment 4•6 years ago
|
||
Do let me know if reopening is not desired, but it's happening again. zone.id was removed 5 days ago, but is still showing at https://publicsuffix.org/list/public_suffix_list.dat
| Assignee | ||
Comment 5•6 years ago
•
|
||
Going to have a look at this.
It would help greatly if I could be made an admin of the github organisation, my github username is 'gozer'
| Assignee | ||
Comment 6•6 years ago
|
||
Once I looked at it carefully, the problem became clear.
The codebuild pipeline deals with 2 repos, the publicsuffix website itself and the publicsuffix list, a different repo.
Even though the pipeline was correctly using both sources and bundling them before sending down to the code build job, the code build job itslef was only making use of the website repo artifacts. It then just plain used wget against github to try and retrieve the latest version of the list, completely side-stepping the source-control versioning process. I suspect this got caught by some caching on github's side of things and ended up with the wget sometimes getting the previous version of the .dat file.
I've now fixed this on the codebuild job itself, and it's not talking to github anymore, but rather, correctly using the generated git artifacts from the pipeline. Should fix the problem once and for all in AWS
Description
•