Fixes opentofu/opentofu#1131: Provide releases page

[ghost]

This is a PoC for opentofu/opentofu#1131. Probably needs cache configuration in Cloudflare.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	f74cdfe
Status:	✅  Deploy successful!
Preview URL:	https://922481a4.opentofu-get.pages.dev
Branch Preview URL:	https://releases-page.opentofu-get.pages.dev

View logs

[ghost]

Preview URL: https://releases-page.opentofu-get.pages.dev/releases/

[ghost]

This PR should be closed and a new one created that statically generates these pages and pushes them to Cloudflare or GitHub pages.

[sanskruti-shahu]

After going through this PR and related issue, my understanding is that this issue proposes providing dedicated HTML pages which will be pushed to Cloudflare or as Github pages instead of relying on the GitHub API for accessing release artifacts (These HTML pages would be containing links to the release artifacts, something similar to this ). Please let me know if I am missing something.

[ghost]

@sanskruti-shahu you are correct, this is the desired functionality with a slight preference to Cloudflare due to the amount of traffic this page could potentially get.

[sanskruti-shahu]

I was thinking of using next.js for statically generating the site which will have a github api call at build and it will pre-render all the required pages based on this api's response at build point so the website generated will be static, and then deploy it through cloudflare. what do you think?

[ghost]

I have no experience with Next.js, but I think the preference would be for a tool that doesn't need constant security updates which the NPM ecosystem is unfortunately notorious for. Please pick a tool that has a small number of dependencies. (In Go, this would be doable without any dependencies at all.)

[sanskruti-shahu]

Ok, so if we would be using go then for this Hugo is used for statically generating sites. I don't know much about it, I'll do some research on how to use it and will get back to you.

[nitrocode]

Thanks for working on this.

For what it's worth, for tfswitch to read this page and parse correctly, it would require 1:1 with hashicorp page. I noticed on your page that the versions are not prefixed by tofu_ and there is a v prefix which doesn't exist in hashicorps page.

If the format is changing then tools like tfswitch will need to update how they parse the page which would be more work for maintainers.

Is the format change deliberate or is it a bug?

For comparison

• hashicorp https://releases.hashicorp.com/terraform/
• opentofu https://releases-page.opentofu-get.pages.dev/releases/

[ghost]

@sanskruti-shahu please note the comments by @nitrocode this would be important so tooling can use this page properly. (Thanks @nitrocode !)

[Yantrio]

Ok, so if we would be using go then for this Hugo is used for statically generating sites. I don't know much about it, I'll do some research on how to use it and will get back to you.

If we went with the golang route, I personally would recommend just using go templating and no external libs. I don't see a need to use hugo for this. That's complete overkill.

Golang may even be overkill for this!

[sanskruti-shahu]

@Yantrio @janosdebugs , I don't have a background in this, so I'm not sure which option would be the most efficient to use. Could you please provide a recommendation?

[ghost]

@sanskruti-shahu @nitrocode linked the Terraform page from Hashicorp. In order for existing tooling to work, our page needs to look exactly the same, but for OpenTofu of course.

Regarding the templating in Go, you could read the documentation. Generally, I think we are happy with almost any solution that doesn't involve a heavy-weight framework since we need to generate two types of HTML pages.

[nitrocode]

Here's something i whipped up in Python. It's less than 100 lines and it could probably be easily converted into golang templates (if that's the chosen solution to the problem).

opentofu/opentofu#928 (comment)

[sanskruti-shahu]

Hey @janosdebugs ,

I've developed a main.go file that, upon execution, initiates an API call. Depending on the response received, it generates the required html files during the build stage. I thoroughly tested this file locally and on my personal Cloudflare account, and it performed as expected.

But for this process to function correctly, a minor adjustment is needed within the Cloudflare build settings. Specifically, it's essential to configure Cloudflare to execute the command go run main.go (or any other way through which main.go file will be executed) during each new deployment. Once this adjustment is made, all pages will be systematically generated and deployed.

Temp Preview url: https://page-releases.pages.dev/

[nitrocode]

@sanskruti-shahu the output of your file looks 1:1 with hashicorp. Nice job.

Wouldn't it be better to use typescript natively as per the repo code than to tie in golang ?

[sanskruti-shahu]

Hey @nitrocode , I tried writing this same logic to index.ts file but as per cloudflare's typescript it does not allow access to filesystem and so we cannot create extra folder or file to store those html content rather it generates the content dynamically so that's why I had to use golang.

[nitrocode]

Couldn't the paths be dynamically created with typescript in cloudflare without creating native directories?

[sanskruti-shahu]

I am not understanding what you are trying to say.But even if path will be created we will still need those html files as we are generating static site.
Edit - Or maybe I can try again to find an alternative for implementing the same logic using TypeScript.

[ghost]

@nitrocode we are specifically trying to NOT use Cloudflare because a rate limit error would mean that we are delivering a bad result. Instead, this should be statically generated. @sanskruti-shahu please continue with the Go variant.

[nitrocode]

Oh I'm sorry, I misunderstood. I thought cloudflare was the intention, perhaps previously it was and my knowledge of the solution is outdated. Please disregard my previous comment.

[ghost]

Closing in favor of #22