-
-
Notifications
You must be signed in to change notification settings - Fork 81
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
exporting using github actions #140
Comments
This is related to #49 I have thought of this, However, this plugin relies very heavily on obsidian's internal API, which means you would also have to run obsidian in the docker container. While it is posible to run obsidian in a docker container (see https://forum.obsidian.md/t/obsidian-remote-running-obsidian-in-docker-with-browser-based-access/34312) I do not have the know-how to set that up. Additionally, the whole vault would have to be replicated inside the docker container not just the markdown. All this would need to be done automatically. I would be happy to accept a solution if someone comes up with one, but I probably will not work on this myself right now. |
Local REST API for Obsidian can trigger a command: I guess this will make things a lot easier. Now the whole process looks like:
However, this needs some tweak to this plugin's default behavior, because now it asks for confirmation every time before export |
There could just be another command like "Export vault to HTML using default settings" or similar then we can trigger that via the REST api. |
+1 I can't see why running Obsidian in a container would be difficult to set up, from my understanding all plugins, config and files required other than the Obsidian client are self contained within the vault, I will have to give it a go following that thread. Creating a docker image that is pre set up with the rest API, mapped port etc would be a game changer for automating the HTML file generation and deployment entirely. |
Hey thanks, I don't think it would be too hard either. It's all a matter of time and priority. If you want to try setting something up that would be extremely helpful! |
Docker Image from AboveHmm, I had a bit of a crack at using the sytone/obsidian-remote image, but it is somewhat unmaintained and also a bit surplus to the needs of what we need for this issue. It is a VNC server with full browser access to Obsidian, which adds a lot of complexity, although it would be easier to debug. If anyone is going to try and get it working definitely check out this issues thread, the provided I have left my results from today in there. Other IdeaWhat if we used a technique similar to this:
I can see that actually starting obsidian in a container is fairly easy, all of the images I've seen use the appimage, extract it during build steps then at runtime execute a start command similar to this:
I understand that you need the frontend of Obsidian for the plugin to work (@KosmosisDire correct me if I'm wrong), potentially a container with a GUI but with headless only access could work, it would have a lot less things to go wrong. What are your thoughts on this approach? |
Is your feature request related to a problem? Please describe.
Exporting is using too much CPU resources, I propose a feature to support GitHub actions or other CI/CD pipeline softwares like circleCI.
Describe the solution you'd like
I think once #49 is solved. a docker container or something could be built which then can be run on github action runners. I think (I might be wrong here, am I?) this is a solution because it allows using github runners' resources instead of a personal laptop/pc.
Describe alternatives you've considered
Well, an alternative is to find an optimal algorithm for generating and saving generated files. e.g. don't export the same files on all exports. like keeping track of updated files and all. but I feel this also requires to update the base code of the plugin in a major way because when we export just a single file using "Multi-file website" option it doesn't quite export it as a part of the whole website! e.g. it doesn't incorporate TOC in it.
Additional context
to understand the context checkout #49 and #135.
I think just allowing (and making it work, which it is not right now) to choose files to be exported while using "Multi-file website" option could solve this whole problem of CPU resources. but yeah, github action solution could be a great feature in itself.
The text was updated successfully, but these errors were encountered: