Download page using stream metadata

[bgilbert]

The source of truth for release artifact URLs will be the stream metadata (#98). The download page for Fedora CoreOS should fetch the stream metadata client-side and render appropriate links.

Since we won't have bucket or directory indexes for release artifacts, some sort of download page (even an interim one) will be needed for the preview release so users can locate artifacts without reading JSON.

[ghost]

This would normally be a request on https://pagure.io/fedora-websites/issues. Since this is for the preview release, we might not get it on the Fedora Downloads website, though, so we'll probably have to figure out how to do it on the https://coreos.fedoraproject.org/ website.

[bgilbert]

Filed issue against fedora-websites.

[rfairley]

WIP PR at: https://pagure.io/fedora-web/websites/pull-request/39 - will be tidying it further tomorrow.

[rfairley]

Update:

• Download page is working at https://getfedora.org/coreos/download/! Thanks all who helped debug the Flask and CSP issues in #fedora-websites on Freenode.
• [1] was merged for the short-term to avoid using the Vue full build [3], which was previously needed for Vue templating in [2]. The Vue full build uses the JavaScript builtin function eval() and does not comply with the CSP, meaning the content in the inline Vue template could not be rendered as HTML. The compiled JS code in [1] gets around this by including the necessary JS runtime code to render the HTML page.
• Currently now working on a solution that uses the Vue runtime-only build without needing precompiled code, i.e. no Vue templating. This is essentially using the render function as shown in [3]. Although not ideal without templating, this code will be human-readable. Once complete, the compiled code in [1] can be dropped. Planning to keep this issue open until this follow-up is complete.

[1] https://pagure.io/fedora-web/websites/pull-request/43
[2] https://pagure.io/fedora-web/websites/pull-request/39
[3] https://vuejs.org/v2/guide/installation.html#Runtime-Compiler-vs-Runtime-only

[rfairley]

Currently now working on a solution that uses the Vue runtime-only build without needing precompiled code, i.e. no Vue templating.

Opened a PR for this: https://pagure.io/fedora-web/websites/pull-request/44

[rfairley]

Self-note:

Enhancements to make (mentioned in community meeting):

• link AMI IDs on download page to AWS console launch page (actioned)
• improve visibility of Fedora signing key on download page (actioned)
• add advice/blurb to download page on verifying downloads (actioned)
• basic CT/Ignition configs where SSH key just needs to be replaced
• link to getting started guide on downloads page
• copy to clipboard?
• anchors on the page for each section

PR for some of the above (checked off): https://pagure.io/fedora-web/websites/pull-request/46

Longer-term issues left to fix:

• internationalization support
• include coreos-specific CSS in its own file or place in another CSS file (maybe with the other bootstrap classes)? (coreos-download.css can be deleted)
• noscript message
• verify browser support

[rfairley]

To move forward with this, it seems there are 4 options:

1. Continue carrying App.vue somewhere in the websites repo, and committing the generated .js files which are outputted by npm build. This is what https://pagure.io/fedora-web/websites/pull-request/43 introduced. Committing toolchain output is not ideal though.
2. Rewrite the code in App.vue in a way that doesn't use Vue templating, and import the runtime-only build of Vue (which https://pagure.io/fedora-web/websites/pull-request/44 does).
3. Use a lightweight framework with a cleaner syntax than calling render functions in option 2. Something like lit-html gives a syntax similar to Vue templates when rendering components.
4. Integrate npm into the website deployment process, and build the .js files from .vue templates when deploying.

To keep the JS dependencies lightweight (i.e. just pulling in a single JS file), options 2 or 3 would work. If doing option 3, we should make the switch earlier rather than use 2.

Option 4 would allow us to use Vue or any other framework in NPM we choose, but will mean that npm is required when building the website, when most of the other pages don't use it. This approach would provide the most flexibility though.

3 seems feasible and would satisfy our needs, if we agree on a framework that would be easier to maintain compared to the approach in 2. 4 would be nice to have, and is worth discussing how much work it would be.