Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Proper support for GitHub Codespaces / dev containers #2435

Open
4 tasks
InDieTasten opened this issue Feb 10, 2024 · 8 comments
Open
4 tasks

Comments

@InDieTasten
Copy link

InDieTasten commented Feb 10, 2024

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 get_url generates http url during serve, even though base_url defines https #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
Copy link
Collaborator

Keats commented Feb 12, 2024

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

@InDieTasten
Copy link
Author

InDieTasten commented Feb 12, 2024

@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
Copy link

I would find this useful, happy to help @InDieTasten

@InDieTasten
Copy link
Author

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
Copy link
Author

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

The issue for more detailed tracking is located here: InDieTasten#1

@megamorf
Copy link

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
Copy link

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
Copy link
Author

InDieTasten commented Apr 17, 2024

@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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants