Hello, I am interested in prototyping something with Decker and it requires extending some of the core functionality - specifically a way to directly build and deploy the current deck into a GitHub repo via something like a "Deploy..." menu item. I was looking for ways I could do this that would be the most "master branch friendly", to maximize the utility of anything I put together (even if it's just from a exploration standpoint.) I'm imaginging something like a way to add menu elements in a plugin-style approach, where the menu item can kick off a contraption (in this case, a dialog and so on that lets you enter github credentials) and so on that would continue to have access to the 'source deck' that was active prior to the menu item being activated. Thanks for any insight!

I think the simplest approach might be to add a menu item that saves the current document and then invokes a shell script with the path of the document. This would only need to touch a few lines of the C codebase. The shell script could then handle all the minutia of retrieving credentials and manipulating GitHub web APIs, and it would be easy to tweak the script to suit other deployment scenarios: upload to Neocities, rsync with a VPS, etc.

Ah thank you. I was actually planning on doing this for the web version however. I am looking to extend Decker to allow "origin writeback", which would allow a user to edit the Deck "in-place" on their web host, and have the changes automatically sync back to origin via git. (I implemented this for a project called Webspaces, see https://webspaces.space or the writeup here https://gfodor.medium.com/rebooting-the-web-in-3d-with-webspaces-9e58847e042c, decker has similar design goals of long term durability and coherent artifacts, but my project is about 3d multimedia environments not 2d)

Here's where the spec for that API is: https://github.com/WICG/file-system-access