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

exporting using github actions #140

Open
toposopher opened this issue Jun 11, 2023 · 6 comments
Open

exporting using github actions #140

toposopher opened this issue Jun 11, 2023 · 6 comments
Labels
enhancement New feature or request needs planning This feature request is viable but needs revision / discussion before implementation

Comments

@toposopher
Copy link

toposopher commented Jun 11, 2023

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.

@toposopher toposopher added the enhancement New feature or request label Jun 11, 2023
@KosmosisDire
Copy link
Owner

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.

@boyanxu
Copy link

boyanxu commented Jun 21, 2023

Local REST API for Obsidian can trigger a command:

image

I guess this will make things a lot easier. Now the whole process looks like:

  1. Launch obsidian from command line
  2. Issue an HTTP request using curl to trigger command: "Export vault to HTML"

However, this needs some tweak to this plugin's default behavior, because now it asks for confirmation every time before export
image

@Regenhardt
Copy link

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.

@fetwar
Copy link

fetwar commented Nov 2, 2023

+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.

@KosmosisDire
Copy link
Owner

+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!

@fetwar
Copy link

fetwar commented Nov 21, 2023

Docker Image from Above

Hmm, 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 docker-compose.yml files are much, much better than the README.md

I have left my results from today in there.


Other Idea

What if we used a technique similar to this:

  1. Create an Obsidian vault configuration that has REST APIs set for exporting the site, plugins loaded etc
  2. Map that Obsidian vault config and files into a basic docker image
  3. Use a healthcheck to wait for the container to be up and ready
  4. Use a the API endpoint to generate the site files, outputting to another volume

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:

sudo /usr/bin/obsidian --no-sandbox --no-xshm --disable-dev-shm-usage --disable-gpu --disable-software-rasterizer

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs planning This feature request is viable but needs revision / discussion before implementation
Projects
Development

No branches or pull requests

5 participants