Closed Bug 1558748 Opened 7 years ago Closed 6 years ago

Version of PSL at publicsuffix.org not refreshing

Categories

(Infrastructure & Operations :: SRE, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

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.

We fixed this issue, as to why its not updating we will continue to investigate why its not updating via CI

Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED

We just received another report.
https://github.com/publicsuffix/list/issues/852

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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.

Assignee: infra → nobody
Component: Infrastructure: Other → SRE
QA Contact: cshields → jhoward
Assignee: nobody → limed
Assignee: limed → gozer
Status: REOPENED → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → FIXED

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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'

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

Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.