-
Notifications
You must be signed in to change notification settings - Fork 70
Use Knative to host the Knative website #64
Comments
I think it's a nice idea, but I think we lose a lot of the safety and predictability of using Netlify, as well as a lot of the work Richie has done to hook up Netlify to Github, where we see automatic staging builds in the website repo. It also sounds like a fair amount of work for a small tangible benefit -- most folks are not going to care what backend we run the site on. Right now, it is a bit difficult to set up local builds of Netlify, but it's also true that a pretty small number of people are interested in doing that. |
I like it and I'm very much open to the idea but I need to think about this more. Does porting over functionality include GitHub PR integration (ie. build staged draft for preview and also publish new merged content)? As Sam touches on, I'd hate to see any regression from where we've gotten to but appreciate the fact that we would overall gain more control. Thinking further out, who do you envision would own and maintain the Knative site host? Regarding the local builds, I have a PR open to simplify that a bit (PR #62). This is only a baby step since you still need to install Hugo (and postcss) but after cloning both the docs and website repos, you just run scripts/localbuild.sh (and you get a local build that is similar to what happens on Netlify). |
Netlify has been great for bootstrapping our website. As we get closer to GA, we need to be using Knative more in production ways, and this seems like a way to do that with great visibility (both in terms of usage and finding issues, since if the website breaks due to Knative we'll know pretty quickly). I'd love to see our website adopting more of the best practices that we're encouraging with Knative. While my current state would be a regression from current behavior, it shouldn't be too difficult to pull in the rest of the work you've done. I just hadn't done it yet since I wanted to see if this approach would work at all. With Knative Eventing we can trigger a build on changes to any of the repos we pull content from (website, docs, and community), build using Tekton, and then deploy into Knative serving. The real tangible benefit here is to Knative, further validating the pieces we're building, in production for one of the core use-cases (serving HTTP). Having a completely reproducible environment for building, testing, and deploying the website is a nice benefit as well. I'm happy to work on this more if it seems interesting. Maybe we can find a pathway to where we can transition ownership to the engineerings, so the docs team can spend less time managing infrastructure? |
Well, that I'd be in favor of! I thought this plan involved Richie maintaining the new Knative-based version of the site 😂 |
Sounds good to me too. |
Remove default navbar icon
FWIW I have this running against knative/docs PRs where it builds docs and website (HEAD) into a container image that runs on knative/serving using the local build as an entrypoint. |
I spent a little spare time over the weekend looking at containerizing the Knative website so that it could be run on a Knative-compatible host. Turns out it wasn't that hard to move everything into a two-stage
docker build
flow.I haven't moved all of the configuration in the current build script, e.g. supporting PRs.
I've pushed these changes to a fork of this repo, here: https://github.com/rgregg/website/tree/self-hosted, and you can see an example of it running here on Cloud Run: https://knative-website-7jeitjla7a-uc.a.run.app/
I'd love to see us start to dogfood Knative to run our own website. What do other folks think?
Another advantage of this approach is that local-development is super easy, since the whole build and run environment happens inside a container. You don't need to setup any build environment on your local machine, just clone the repo and go. This is a big improvement over getting the build environment setup on your own machine!
Another big advantage is that we can control more of the process. We're not subjected to Netlify changing the version of Hugo we're using under our nose, potentially breaking how our text is rendered.
If this is interesting, I'm happy to keep working on getting the full set of functionality ported over.
The text was updated successfully, but these errors were encountered: