Before you suggest automation guidelines, please consider the contribution guidelines layed out in this document.
-
The guidelines are written in asciidoc as described by Asciidoctor.
-
each guideline is made of one sentence, as easy to remember as possible, followed by a collapsible description, made of:
-
explanations
-
rationale
-
examples
The result looks then as the following template shows (you may copy & paste):
== Do this and do not do that is the guideline [%collapsible] ==== Explanations:: These are explanations Rationale:: This is the rationale Examples:: These are examples + .A mini playbook example [source,yaml] ---- --- - name: A mini example of playbook hosts: all gather_facts: false become: false tasks: - name: Say what we all think ansible.builtin.debug: msg: asciidoctor is {{ my_private_thoughts }} ---- + Even more examples... ====
Notesee how it looks like in the [_example] section below.
-
-
Those guidelines are grouped into sections and optionally sub-sections, as far as required for maintainability.
-
Those (sub-)sections can be written in their own source file, but then are included with
include::directory/file.adoc[leveloffset=1]
in the parent section’s file. This makes sure that all source files are interlinked and can be rendered all together by rendering the topREADME.adoc
, either withasciidoctor
or withasciidoctor-pdf
.Notethis contribution file is obviously not meant for inclusion in the overall document. -
Each source file has a single title (the line starting with one equal sign) and can be rendered individually (the
leveloffset
is set such that it fits in the overall headings structure when included). -
The source code is written as readable as possible in its raw form, without impacting maintainability.
-
We follow the Asciidoc recommended practices.
-
Sentences are written in the present tense form, avoid "should", "must", etc. For example, "Sentences are written", not "Sentences should be written" or "Sentences must be written". This avoids filler words.
-
The singular "they" is used to avoid the unreadable "he/she/it" construct and still be neutral.
-
Just fork the repository, create a Pull Request (PR) and offer your changes.
Tiplimiting each PR to a single recommendation makes it easier to review. This furthermore speeds up approval, which is an advantage also for contributors. -
Feel free to review existing PR and give your opinion
-
Also an issue against one of the recommendations is a valid approach
This is how one guideline as shown above looks like once rendered:
Details
- Explanations
-
These are explanations
- Rationale
-
This is the rationale
- Examples
-
These are examples
A mini playbook example- name: a mini example of playbook hosts: all gather_facts: false become: false tasks: - name: say what we all think debug: msg: asciidoctor is {{ my_private_thoughts }}
Even more examples…
Use for now the following manual command to publish to the website:
asciidoctor -a toc=left -D docs -o index.html README.adoc
asciidoctor -a toc=left -D docs CONTRIBUTE.adoc
mkdir -p docs/images
cp -v images/*.svg docs/images
Note
|
it doesn’t seem that there is any much better way to keep links to images correct according to the HTML generation / managed images chapter. |
If you run (a current) Fedora Linux,
then you can use the Makefile
.
-
make view
generates both PDF files and displays the GPA guide -
make print
prints to your default printer -
make spell
runs hunspell for spellchecking -
…
Alternatively, use the following manual commands to generate the 2 PDFs:
asciidoctor-pdf \
--attribute=gitdate=$(git log -1 --date=short --pretty=format:%cd) \
--attribute=githash=$(git rev-parse --verify HEAD) \
--out-file Good_Practices_for_Ansible.pdf \
README.adoc
asciidoctor-pdf \
--attribute=gitdate=$(git log -1 --date=short --pretty=format:%cd) \
--attribute=githash=$(git rev-parse --verify HEAD) \
--out-file Contributing-to-GPA.pdf \
CONTRIBUTE.adoc