| Age | Commit message (Collapse) | Author |
|---|
|
Build time feature flags are now defined in cloudinit/features.py.
Feature flags can be added to toggle configuration options or
deprecated features. Feature flag overrides can be placed in
cloudinit/feature_overrides.py. Further documentation can be found in
HACKING.rst.
Additionally, updated default behavior to exit with an exception
if #include can't retrieve resources as expected. This behavior
can be toggled with a feature flag.
LP: #1734939
|
|
|
|
Hopefully this will save some ~pointless round trips on CLA PRs.
|
|
|
|
This (a) gives people an easy way of getting a commit into the codebase,
and (b) saves us from having to explain this process (or do it
ourselves) for every new contributor.
|
|
Specifically:
* include warning against general use of mock assert methods (and suggestions on how to replace them)
* add guidelines on test decorator/param ordering
* add test guideline for module-level mock variables
|
|
* HACKING.rst: add list of available pytest fixtures
* HACKING.rst: capture common mock naming pattern in codebase
|
|
And document that we can't yield in pytest.fixture functions due to the
age of xenial's pytest.
|
|
* Split the "existing contributors" information out to a separate
section
* Update the "Do these things once" CLA information for the current
process
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Joshua Powers <josh.powers@canonical.com>
|
|
|
|
The previous language suggested that only people who had signed the CLA
previously needed to prove their GH identity, which is not the case.
|
|
Start a design decision area in HACKING to capture highlevel decisions.
First example is to capture the use of _ over - in cloud config
modules.
LP: #1293254
|
|
|
|
In the Hacking doc, change the contact information for the contributors
agreement to reference Josh Powers rather than Scott Moser.
|
|
Just include mention of setting user name and email when first
setting up git.
|
|
When signing the Contributors agreement, the user is prompted to provide
a 'Project contact' or 'Canonical Project Manager'.
Just update the HACKING.rst document to tell them what to put there.
|
|
The biggest things here are:
* move doc/sources/*/README.rst to doc/rtd/topics/datasources
This gives each datasource a page in the rtd docs, which make
it easier to read.
* consistently use the same header style throughout.
As suggested at
http://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html
use:
# with overline, for parts
* with overline, for chapters
=, for sections
-, for subsections
^, for subsubsections
“, for paragraphs
Also, move and re-format vendor-data documentation to rtd.
|
|
Put a bit more information and a few style fixes in HACKING.rst.
|
|
- Update HACKING.rst to include git instructions
- update MANIFEST.in and .gitignore to ignore git-related things
- replaced tarball generation scripts with git-based script
- have the spec files correctly identify themselves as cheetah templates
- make brpm work with git
|
|
pylint was not passing, and per smoser in IRC pylint can/should be
removed.
|
|
Start moving the current README for
datasources to a RST format and include
those files in the rtd site.
LP: #1113650
|
