Closed rzach closed 4 years ago
Sounds good. I think we should probably move documentation out of the "shared" system once this is ready to go. That will simplify things considerably.
On Thu, Sep 24, 2020, 12:37 PM Richard Zach notifications@github.com wrote:
Well, I haven't done anything yet, since I didn't want to put in work I'd have to undo because the documentation I start from has changed.
I suggest the way to do this is:
- implement the scripts/Github action/cron job that pulls the MD files from here and changes them on the server when they change in the repo;
- populate the repo with existing documentation, and freeze the documentation;
- test if it works ok;
- when it works, start improving the documentation incrementally, and make any changes to existing documentation here only.
If we want the documentation to remain in the shared files and be searchable/filterable by tag there, the script that inserts the MD file will need a way to take/overwrite things like page title, description, tags, and possibly restrictions (if we want some things only be available to instructors, say, although since this repo is public, maybe everything can just be public).
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/Carnap/Carnap-Documentation/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQWOFKGN4B72CTLEYMAJMTSHN7UDANCNFSM4RYSSTNQ .
We might want to do something like the front-matter as is used in Hugo and other static site generators: there's a block of YAML/TOML/etc metadata with separators at the top of the file. Here's an example file arbitrarily grabbed from my blog content folder.
I personally would like if everything were public, mostly for selfish reasons 😅 as I'm not an instructor on Carnap.io (since I'm primarily a developer/instance admin and don't really need to be one otherwise).
That's a good idea. Pandoc has pretty good support for yaml metadata:
https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
Fields? title
, author
, draft
,tags
all seem good. Anything else?
Those seem good, though we probably also want a unique ID so we can't accidentally clobber documents if we have name collisions or renaming. Thoughts on implementation strategy? We could add another executable in the Carnap repo that imports Carnap-Server to do the documentation updates through its logic, or some other strategy. I imagine we probably have to change the database records for the documents based on the pandoc metadata, right?
I tihink I'm going to add a new route for handling "unowned" documents, including this documentation. So, it'll basically just serve up the hereditary contents of a directory, without any DB entanglement. That way, we can sync with just a git pull
!
Ok, the new route is up and running. Here's an example: https://carnap.io/srv/doc/forallx.md
Just need to put a script on a timer for the git pull.
Nice work! I think it will also need an index, which we should possibly (?) manually create, perhaps with the README?
It's set up to use index.md, if present in the docs directory so that should do the trick.
Yes! Done!
OK, everything is now automated. The server will pull from this repository daily.
Well, I haven't done anything yet, since I didn't want to put in work I'd have to undo because the documentation I start from has changed.
I suggest the way to do this is:
If we want the documentation to remain in the shared files and be searchable/filterable by tag there, the script that inserts the MD file will need a way to take/overwrite things like page title, description, tags, and possibly restrictions (if we want some things only be available to instructors, say, although since this repo is public, maybe everything can just be public).