Hacker Newsnew | past | comments | ask | show | jobs | submit | bo0tzz's commentslogin

I loaded up the hacker news dataset in google bigquery, which turned out https://news.ycombinator.com/item?id=42057647 as the biggest at 9624 comments. Second is https://news.ycombinator.com/item?id=43208973 at 5349.

reply


Link to the API https://github.com/HackerNews/API (copied from the bottom of the page)

reply


The post mentions 743 LOC records in the entire database; I'd be very curious to hear what that number's at now?

reply


I will ask someone to find out and report back.

reply


The answer is... 2,386 LOC records.

reply


How many of those additional 1,643 were a result of your 2014 blog post? :)

reply


Their example in the blog post, geekatlas.com, no longer provides an LOC!

reply


Any chance of convincing someone to do a stat dump on all record types?

reply


> correctly classified as having user generated active content

No it's not

> PRs can be autodeployed to this domain without passing review or approval.

No they can't

There is no untrusted/user content on these domains.


As I've mentioned in several other comments in this thread by now: The whole preview functionality only works for internal PRs, untrusted ones would never even make it to deployment.


> unless one of the developers in the team published something malicious through that system

If that happened we'd have much bigger problems than Google's flagging.


> Google flagged this domain for legitimate reasons.

No they didn't.


There is no user generated content involved here.


The Immich domains that are hit by this issue are -not- user generated content.


They clearly are? It seems like GitHub users submitting a PR could/can add a `preview` label, and that would lead to the application + their changes to be deployed to a public URL under "*.immich.cloud". So they're hosted content generated by users (built application based on user patches) on domains under their control.


I'm the guy that built the system, lol. Labels can only be added by maintainers, and the whole system only works for PRs from internal branches.


Ah, then that's a different situation then, sorry for misunderstanding the context and thanks for clearing that up! I was under the impression that Immich accepted outside contributions, and those would also have those preview sites created for their pending contributions.


The workflow is fundamentally unable to deploy a PR from a fork, it only works for internal branches, as it relies on the container image being pushed somewhere which needs secrets available in the CI workflow.


Sounds like you're hitting an address that isn't backed by any service, not sure what the issue is.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: