If I understand the requirements correctly, this approach appears way over complicated.
If the Downloads page only changes when there is a release, I would auto-generate a static html site as part of the CI/CD release process, then upload and serve it via s3. Then to optimise the s3 costs have either CloudFront or Cloudflare to reverse proxy the static html.
That isn't how this works... If people show-case something they've done via a blog post, then it is submitted to HN for comments, then people comment on it, including an an analysis of the approach. If people like it, they'll say so... if people feel it could be better, then they'll share their thoughts on how it could be improved.
You saying it is the best approach because it is now done that way, is illogical and doesn't promote better ways.
Of course, the approach I outlined /may/ not be better.. and I may have misunderstood the requirements. I welcome critical analysis of what I proposed, but you haven't done that.
However, I am keen to help... so if you are happy to validate the requirement and approach with upstream, and confirm it will be well received I will write a golang drone-ci compatible static site generator that generates near identical html output from the s3 listing they could replace it with.
If the Downloads page only changes when there is a release, I would auto-generate a static html site as part of the CI/CD release process, then upload and serve it via s3. Then to optimise the s3 costs have either CloudFront or Cloudflare to reverse proxy the static html.
How is the approach documented better than that?