Feature request: Proper support for GitHub Codespaces / dev containers

[InDieTasten]

There are many issues users of GitHub Codespaces are facing when trying to build sites using zola:

1. There is no container image that can be used as dev container (which in turn requires extra script steps to install zola in other images, like alpine)
2. When trying to use zola serve, the way tunneling is setup in GitHub Codespaces url's are breaking (see #2434)
3. Live reload will not work due to the same tunneling and address / port remapping
4. No documentation for how to effectively use zola in GitHub Codespaces

I found a blog post of another developer who tried using zola in Codespaces as well: https://piannaf.com/blog/zola-in-codespaces/ He figured out a hacky way to get it to work, though I wouldn't call it a solution.

---

Proposal

• [ ] Add --base-url-override option, that takes schema://hostname:port/segment and sets it up for URL generation inside zola
• [ ] Adapt live_reload websocket endpoint to be handled on the same port as the http endpoint. This way only a single tunnel needs to be used that can be authenticated using http. The websocket should then also be authenticated already. This way, we do not need to make port mapping public in order to use live_reload.
• [ ] Create a devcontainer-feature specification for zola
• [ ] Add docs for using zola inside of Codespaces by making use of the devcontainer feature and --base-url-override option

[Keats]

I didn't even know about GitHub Codespaces until now so it would have to all come from PRs.

[InDieTasten]

@Keats I could definitely take a stab at this. Feel free to assign this to me, if you want me to explore this further and possibly create a PR for adding support.

[darrenmeehan]

I would find this useful, happy to help @InDieTasten

[InDieTasten]

I've drafted up a rough plan for how to achieve codespaces support in the description of this issue. @Keats Let me know, if you see any issues with that approach in regards to the rest of the system. I'm honestly not sure about the live reload websocket handling, so that part is more of an experiment than anything else ^^

@darrenmeehan I'll create a fork, add you as contributor and create some sub-issues within the fork. We can discuss within the fork, how we work together most effectively :)

I will also link the fork in here, once I've created it.

[InDieTasten]

The fork for implementing this is located here: https://github.com/InDieTasten/zola-codespaces

The issue for more detailed tracking is located here: https://github.com/InDieTasten/zola-codespaces/issues/1

[megamorf]

I also ran into this - in my case I'm not using GitHub Codespaces but a self-hosted VS Code with the Remote Tunnels feature where Microsoft provides a central domain to securly access my VS Code instance from anywhere.

At the moment I'm not able to access the zola serve process because it returns a Encountered an error: WebSocket Protocol Error: Unable to parse WebSocket key error that I don't have with other SSGs like Hugo or Jekyll.

[nicodoggie]

Just so people can dev for zola quickly, it might be quicker to implement a -disable-livereload flag for serve. Could that be an idea so that livereload.js doesn't block other assets from loading in the meantime?

[InDieTasten]

@nicodoggie I don't think implementing a new option for that is a good idea. It would change the interface for a temporary workaround. Also, the serve endpoint needs to be updated anyways due to

• #2465

It's just that I've been too busy the last couple weeks to dive into this again. However, if there is anyone interested in helping, that would be greatly appreciated.

[Keats]

@InDieTasten any update on that?

[InDieTasten]

@Keats I'm currently very busy. I can push my WIP tonight. It's got the package updates in the cargo.toml figured out, but not yet modified the serve functionality to work with the new hyper types from v1