mirror of
https://github.com/ldericher/autodoc.git
synced 2025-12-06 15:43:01 +00:00
Major README refactoring
This commit is contained in:
parent
f383563acb
commit
e782a6f5ea
1 changed files with 60 additions and 28 deletions
90
README.md
90
README.md
|
|
@ -1,51 +1,87 @@
|
||||||
# autodoc
|
# autodoc
|
||||||
|
|
||||||
[`autodoc`](https://github.com/ldericher/autodoc) is a simple [CI](https://en.wikipedia.org/wiki/Continuous_integration) script, primarily aimed at document creation.
|
[`autodoc`](https://github.com/ldericher/autodoc) is a simple [CI](https://en.wikipedia.org/wiki/Continuous_integration) system optimized for document creation.
|
||||||
|
|
||||||
## Basics
|
## Quick Start Guide
|
||||||
|
|
||||||
`autodoc` relies upon [inotify-tools](https://github.com/rvoicilas/inotify-tools) to recursively watch a Linux file system directory.
|
1. Install [Docker CE](https://docs.docker.com/install/)
|
||||||
|
|
||||||
For each file change, `autodoc` searches corresponding build instruction files (Makefiles etc.) and kicks off build processes accordingly.
|
1. Clone or download the `autodoc` repository, open a terminal inside the [example_docs](https://github.com/ldericher/autodoc/tree/master/example_docs) directory
|
||||||
|
|
||||||
## Usage
|
1. Deploy an `autodoc` container:
|
||||||
|
```bash
|
||||||
|
docker run --rm -it \
|
||||||
|
--name autodoc \
|
||||||
|
--volume "${PWD}":/docs \
|
||||||
|
--user "$(id -u):$(id -g)" \
|
||||||
|
ldericher/autodoc
|
||||||
|
```
|
||||||
|
|
||||||
`autodoc` is designed to run in a server-side, containerized context.
|
The contents of the directory are now being watched by `autodoc`!
|
||||||
|
|
||||||
### Deploy a container
|
|
||||||
|
|
||||||
`autodoc` can be pulled from the docker hub using `docker pull ldericher/autodoc`.
|
|
||||||
|
|
||||||
When deploying an `autodoc` container, mount your document root to `/docs`. You *should* also set the container's UID and GID.
|
When deploying an `autodoc` container, mount your document root to `/docs`. You *should* also set the container's UID and GID.
|
||||||
|
|
||||||
#### Included software
|
1. Edit some stuff, save, then watch the magic (and the terminal output)
|
||||||
|
|
||||||
TODO `ldericher/autodoc` contains `pandoc`.
|
## Where not to use `autodoc`
|
||||||
|
|
||||||
#### tl;dr
|
`autodoc` is **not** a solution for Continuous Integration of large scale systems software! `autodoc` excels at building a large number of independent, small files.
|
||||||
|
|
||||||
Deploy an `autodoc` instance in your current working dir:
|
## Prime use case: Nextcloud
|
||||||
|
|
||||||
docker run --name autodoc -d -v "${PWD}":/docs --user "$(id -u):$(id -g)" ldericher/autodoc
|
Nextcloud is a "safe home for all your data" that can [easily be deployed using docker-compose](https://hub.docker.com/_/nextcloud).
|
||||||
|
Add an `autodoc` container to create directories where PDFs are automatically held up to date for all your documents. This extends upon the "[Base version - apache](https://hub.docker.com/_/nextcloud#base-version---apache)" of the Nextcloud compose deployment.
|
||||||
|
|
||||||
### Automating builds
|
```yaml
|
||||||
|
version: '2'
|
||||||
|
|
||||||
Example automated builds can be found [here](https://github.com/ldericher/autodoc/tree/master/example_docs).
|
volumes:
|
||||||
|
documents:
|
||||||
|
|
||||||
In general, just put a build instruction file into any (sub-)directory watched by `autodoc` and add your source files.
|
services:
|
||||||
|
app:
|
||||||
|
volumes:
|
||||||
|
- documents:/opt/autodoc
|
||||||
|
|
||||||
|
autodoc:
|
||||||
|
restart: always
|
||||||
|
image: ldericher/autodoc
|
||||||
|
user: "UID:GID"
|
||||||
|
volumes:
|
||||||
|
- documents:/docs
|
||||||
|
```
|
||||||
|
|
||||||
|
The "user" key should be set to the same numeric IDs used for the nextcloud worker processes! To find the right IDs, issue `docker-compose exec app sh -c 'id -u www-data; id -g www-data'`.
|
||||||
|
For the apache containers, this should evaluate to "33:33".
|
||||||
|
|
||||||
|
To begin, add the mounted `/opt/autodoc` as a local external storage to your Nextcloud instance.
|
||||||
|
You might need to setup the permissions on your new volume using `docker-compose exec app chown -R www-data:www-data /opt/autodoc`.
|
||||||
|
|
||||||
|
## Basic functionality
|
||||||
|
|
||||||
|
`autodoc` uses `inotifywait` from [inotify-tools](https://github.com/rvoicilas/inotify-tools) to recursively watch a Linux file system directory.
|
||||||
|
|
||||||
|
For each file change, `autodoc` searches relevant build instruction files (Makefiles etc.) and kicks off build processes accordingly.
|
||||||
|
|
||||||
|
## Concept: Source patterns
|
||||||
|
|
||||||
|
To avoid unnecessary rebuilds and self-triggering, `autodoc` uses "source patterns" to filter for the relevant build instructions.
|
||||||
|
A source pattern is a `bash` regular expression matching any filename that should be regarded as a "source file" to the build instruction file.
|
||||||
|
|
||||||
|
For instance, if a Makefile instructs how to build from Markdown source files, that Makefile's source pattern should likely be `\.md$`.
|
||||||
|
|
||||||
|
## Creating an automated build
|
||||||
|
|
||||||
|
In general, just put your source files into any (sub-)directory watched by `autodoc`. Add a build instruction file.
|
||||||
|
|
||||||
On each file change, its containing directory is searched for a build instruction file. Watched parent directories are also probed for further build instructions.
|
On each file change, its containing directory is searched for a build instruction file. Watched parent directories are also probed for further build instructions.
|
||||||
Every relevant instruction file will be executed as found.
|
Every relevant instruction file will be executed as found.
|
||||||
|
|
||||||
You may combine build instruction systems to your liking.
|
You may combine build instruction systems to your liking.
|
||||||
|
|
||||||
#### SRCPAT concept, "relevant" build instructions
|
## Build instruction systems
|
||||||
|
|
||||||
To avoid unnecessary rebuilds and self-triggering, `autodoc` uses "source patterns" to decide which build instructions are relevant.
|
### GNU Make (Makefiles)
|
||||||
|
|
||||||
For instance, if a build instruction file describes building anything from Markdown files, its source pattern should be something like `\.md$` to match files with ".md" as last extension. Source patterns are `bash` regular expressions.
|
|
||||||
|
|
||||||
#### GNU Make (Makefiles)
|
|
||||||
|
|
||||||
`autodoc` supports standard Makefiles.
|
`autodoc` supports standard Makefiles.
|
||||||
`Makefile`s must contain a SRCPAT annotation comment as follows, where `<regex>` is the source pattern as above.
|
`Makefile`s must contain a SRCPAT annotation comment as follows, where `<regex>` is the source pattern as above.
|
||||||
|
|
@ -56,7 +92,7 @@ For instance, if a build instruction file describes building anything from Markd
|
||||||
|
|
||||||
If there are multiple SRCPAT annotations, the lowermost one will be used.
|
If there are multiple SRCPAT annotations, the lowermost one will be used.
|
||||||
|
|
||||||
##### Advanced options
|
##### Advanced Make options
|
||||||
|
|
||||||
You may add a PHONY target "autodoc" which will be built *instead* of the default target.
|
You may add a PHONY target "autodoc" which will be built *instead* of the default target.
|
||||||
|
|
||||||
|
|
@ -65,7 +101,3 @@ You may add a PHONY target "autodoc" which will be built *instead* of the defaul
|
||||||
autodoc:
|
autodoc:
|
||||||
@echo "Hello World!"
|
@echo "Hello World!"
|
||||||
```
|
```
|
||||||
|
|
||||||
## What not to use `autodoc` for
|
|
||||||
|
|
||||||
`autodoc` excels at building a large number of independent small files. It is **not** a solution for Continuous Integration of large scale software systems!
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue