Install-types are a user facing feature, not just for developers. Lets
move the docs on them in to the user guide.
Change-Id: I6ee8f657c270cf90da9c0729494740bb23aa47c5
Now 'tox -efunc' can be invoked to run all functional tests in
the 'venv' tox environment. Also `tox -efunc element-name` can be
used to run function tests for one element (e.g. ironic-agent).
Change-Id: Ia685d1b2a7deef2f8b98876ac09792134dd30f2f
Use inline code syntax for env variables.
Link to elements README files.
Point 'redhat' to 'redhat-common' instead.
Change-Id: Ied1150aaa631c7c6d7f2f55314f9aa3529fd4ba0
Augment the developing_elements.rst by taking advantage of Sphinx
markup. Most of the doc used to be in /README.md and thus did not
leverage on Sphinx.
Use inline codeblock to denote variables, files, command: ``foo``
Phase Subdirectories:
List phase names in the preliminary introduction
Get rid of lists in favor of definitions
Highlight whether the phase runs in or outside the chroot
Input parameters are now lists
Use definition lists in Dependencies and Ramdisk sections.
Link to elements README when they exist.
Testing Element: split into two subsections: 'shell' and 'python'.
Use "sourcecode:: sh" for the couple examples at the very top and very
bottom of the document.
Change-Id: I2421f76ec452cac243ccb2208f88c7d320ffedd3
The README.rst has a lot of information that has been duplicated in the
Sphinx maintained documentation (3600330).
Remove dupes from README.rst
Point to http://docs.openstack.org/developer/diskimage-builder/
Change summary:
=====================+======================================
README.md | Sphinx document
section |
=====================+======================================
Installation | installation.rst
---------------------+--------------------------------------
Invocation | invocation.rst
---------------------+--------------------------------------
Requirements | installation.rst Speedups
---------------------+--------------------------------------
Caches/offline | caches.rst + changes from 849e9cb2
| fix some markup
---------------------+--------------------------------------
Install Types | install_types.rst
---------------------+--------------------------------------
Writing an element | developing_elements.rst + fe7823a2
| `Testing element` from b9b6640f
| `3rd party elements' from f1e7bf3a
---------------------+--------------------------------------
Existing elements | elements.rst
---------------------+--------------------------------------
What tools are there | components.rst
---------------------+--------------------------------------
Design | design.rst
---------------------+--------------------------------------
Change-Id: I578daa8e3a8d876b3ee3c9a748d7c8aa2bf7a0b7
jenkin => jenkins
on ci.md
documention => documentation
on developer/caches.html
typicallly => typically
on developer/developing_elements.html
Closes-Bug: #1476993
Change-Id: Ie40205debad5dbc6074e65672e0f3ebeaee5b08e
Having data files in the phase subdirs is an easy source of confusion
in reviews (especially when the data file is a script) and theres really
no reason to be putting data files there at this point. Lets make a
convention out of not doing this.
Change-Id: I99571a2a49e14e8c709af20f6d13d662ac745eb4
Adding a test function which allows us to use elements to perform
element-specific tests. In order for this to work sanely, also adding
some configuration to our break system so we can assert on negative
tests.
Also adding a test for apt-sources to verify this code actually works.
Change-Id: I378a74255010eca192f5766b653f8a42404be5ea
Add a small documentation paragraph about the operating system elements,
what they are required to provide (and thus what other elements can rely
on).
This makes DISTRO_NAME a prime-class variable, which can now be assumed
to always exists (it was de-facto required so far).
Change-Id: Iffbc69de0516b58bfde48e87cd73073428d66b05
Set the pbr option 'warnerrors' to make build_sphinx turns warnings into
error. Fix all warnings.
`tox -edocs` will thus abort whenever someone introduce a new error.
Change-Id: Id6d09768a241866e1fdc1a1e2bf90336f5c5087d
Our docs are very developer focused. Lets create a separate user guide
to help new users get started.
Change-Id: I8a03920e6d3306dd0405177875ea55ccb4b40fea
Rework the list as a definition list.
Mark literal code snippets as literal code snippets.
Fix heading typo.
Change-Id: Ie3d393a49914779f12f3075ff2ac2df5ecf78321
This makes the docs site a lot more manageable and begins moving us in
the direction of separate user and developer docs.
Change-Id: I1650ef9d5be1733b8bc118d99090143cb5b06102
