From e9dbebfa57187dea49631ea1669ec9c0c244cd3a Mon Sep 17 00:00:00 2001 From: John R Barker Date: Fri, 29 Jun 2018 11:12:01 -0700 Subject: [PATCH] Fix some broken links (#42079) * Fix some broken links * We now only serve via https * redirects don't work with anchors, so update those links (devel/dev_guide) --- CODING_GUIDELINES.md | 34 +++++++++---------- Makefile | 2 +- .../docsite/rst/scenario_guides/guide_aci.rst | 2 +- .../rst/vmware/scenario_clone_template.rst | 2 +- examples/DOCUMENTATION.yml | 3 +- lib/ansible/modules/cloud/ovirt/README.rst | 2 +- test/legacy/Makefile | 2 +- 7 files changed, 23 insertions(+), 24 deletions(-) diff --git a/CODING_GUIDELINES.md b/CODING_GUIDELINES.md index 4c3335b21ea..575e77e8186 100644 --- a/CODING_GUIDELINES.md +++ b/CODING_GUIDELINES.md @@ -12,7 +12,7 @@ Language ======== * While not all components of Ansible must be in Python, core contributions to the Ansible repo must be written in Python. This is to maximize the ability of everyone to contribute. - * If you want to write non-Python ansible modules or inventory scripts, that's fine, but they are not going to get merged in most likely. Sorry!! + * If you want to write non-Python ansible modules or inventory scripts, that's fine, but they are not going to get merged in most likely. Sorry!! PEP 8 and basic style checks ============================ @@ -20,7 +20,7 @@ PEP 8 and basic style checks * [PEP 8](https://www.python.org/dev/peps/pep-0008/) is a great Python style guide, which you should read. * PEP 8 must not be strictly followed in all aspects, but most of it is good advice. * The line is limited to 160 characters. - * To run checks for things we care about, use [ansible-test](https://docs.ansible.com/ansible/dev_guide/testing_pep8.html#running-locally). + * To run checks for things we care about, use [ansible-test](https://docs.ansible.com/ansible/devel/dev_guide/testing_sanity.html). * Similarly, additional checks can be made with "make pyflakes". * There is no need to submit code changes for PEP 8 and pyflakes fixes, as these break attribution history. Project leadership will make these periodically. * Do not submit pull requests that simply adjust whitespace in the code. @@ -28,7 +28,7 @@ PEP 8 and basic style checks Testing ======= - * Much of ansible's testing needs are in integration, not unit tests. Add module tests there. + * Much of Ansible's testing needs are in integration, not unit tests. Add module tests there. * That being said, there are unit tests too! * Code written must absolutely pass tests (i.e. "make tests") * You should anticipate any error paths in your code and test down those error paths. @@ -42,7 +42,7 @@ Whitespace Shebang Lines ============= - + * /usr/bin/scripts should start with '/usr/bin/env python' * module code should still use '/usr/bin/python' as this is replaced automatically by 'ansible_python_interpreter', see the FAQ in the docs for more info. @@ -60,13 +60,13 @@ Classes * With the exception of module code (where inline is better), it is desirable to see classes in their own files. * Classes should generally not cause side effects as soon as they are instantiated, move meaningful behavior to methods rather than constructors. - + Functions and Methods ===================== * In general, functions should not be 'too long' and should describe a meaningful amount of work * When code gets too nested, that's usually the sign the loop body could benefit from being a function - * Parts of our existing code are not the best examples of this at times. + * Parts of our existing code are not the best examples of this at times. * Functions should have names that describe what they do, along with docstrings * Functions should be named with_underscores * "Don't repeat yourself" is generally a good philosophy @@ -161,24 +161,24 @@ All contributions to the core repo should preserve original licenses and new con Module Documentation ==================== -All module pull requests must include a DOCUMENTATION docstring (YAML format, -see other modules for examples) as well as an EXAMPLES docstring, which is free form. +All module pull requests must include a DOCUMENTATION docstring (YAML format, +see other modules for examples) as well as an EXAMPLES docstring, which is free form. -When adding new modules, any new parameter must have a "version_added" attribute. -When submitting a new module, the module should have a "version_added" attribute in the +When adding new modules, any new parameter must have a "version_added" attribute. +When submitting a new module, the module should have a "version_added" attribute in the pull request as well, set to the current development version. Be sure to check grammar and spelling. -It's frequently the case that modules get submitted with YAML that isn't valid, -so you can run "make webdocs" from the checkout to preview your module's documentation. -If it fails to build, take a look at your DOCUMENTATION string +It's frequently the case that modules get submitted with YAML that isn't valid, +so you can run "make webdocs" from the checkout to preview your module's documentation. +If it fails to build, take a look at your DOCUMENTATION string or you might have a Python syntax error in there too. Python Imports ============== -To make it clear what a module is importing, imports should not be sprinkled throughout the code. +To make it clear what a module is importing, imports should not be sprinkled throughout the code. Python Imports should happen at the top of the file, exempting code from module_utils. @@ -203,7 +203,7 @@ Exceptions ========== In the main body of the code, use typed exceptions where possible: - + # not this raise Exception("panic!") @@ -265,7 +265,7 @@ Use 'in': # not this: if x.find('foo') != -1: - # this: + # this: if 'foo' in x: String checks @@ -296,7 +296,7 @@ Always do "git pull --rebase" and "git rebase" vs "git pull" or "git merge". See Always create a new branch for each pull request to avoid intermingling different features or fixes on the same branch. - + Python Version Compliance ========================= diff --git a/Makefile b/Makefile index f1b6ef0a5c5..5f6b4d46012 100644 --- a/Makefile +++ b/Makefile @@ -9,7 +9,7 @@ # make deb-src -------------- produce a DEB source # make deb ------------------ produce a DEB # make docs ----------------- rebuild the manpages (results are checked in) -# make tests ---------------- run the tests (see https://docs.ansible.com/ansible/dev_guide/testing_units.html for requirements) +# make tests ---------------- run the tests (see https://docs.ansible.com/ansible/devel/dev_guide/testing_units.html for requirements) # make pyflakes, make pep8 -- source code checks ######################################################## diff --git a/docs/docsite/rst/scenario_guides/guide_aci.rst b/docs/docsite/rst/scenario_guides/guide_aci.rst index 33ee4e5578d..d788cb7829c 100644 --- a/docs/docsite/rst/scenario_guides/guide_aci.rst +++ b/docs/docsite/rst/scenario_guides/guide_aci.rst @@ -65,7 +65,7 @@ For instance ensuring that a specific tenant exists, is done using the following description: Customer XYZ state: present -A complete list of existing ACI modules is available for the latest stable release on the :ref:`list of network modules `. You can also view the `current development version `_. +A complete list of existing ACI modules is available for the latest stable release on the :ref:`list of network modules `. You can also view the `current development version `_. Querying ACI configuration .......................... diff --git a/docs/docsite/rst/vmware/scenario_clone_template.rst b/docs/docsite/rst/vmware/scenario_clone_template.rst index 190ad19ca39..508da442382 100644 --- a/docs/docsite/rst/vmware/scenario_clone_template.rst +++ b/docs/docsite/rst/vmware/scenario_clone_template.rst @@ -209,5 +209,5 @@ Appendix - [1] - https://docs.ansible.com/ansible/latest/vault.html -- [2] - http://docs.ansible.com/ansible-tower/latest/html/userguide/credentials.html +- [2] - https://docs.ansible.com/ansible-tower/latest/html/userguide/credentials.html diff --git a/examples/DOCUMENTATION.yml b/examples/DOCUMENTATION.yml index 49fc2125baf..86d577affc9 100644 --- a/examples/DOCUMENTATION.yml +++ b/examples/DOCUMENTATION.yml @@ -2,8 +2,7 @@ # If a key doesn't apply to your module (ex: choices, default, or # aliases) you can use the word 'null', or an empty list, [], where # appropriate. -# -# See https://docs.ansible.com/ansible/dev_guide/developing_modules_documenting.html for more information +# See https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_documenting.html for more information # module: modulename short_description: This is a sentence describing the module diff --git a/lib/ansible/modules/cloud/ovirt/README.rst b/lib/ansible/modules/cloud/ovirt/README.rst index a5cbf0ccd65..fc72b7a780e 100644 --- a/lib/ansible/modules/cloud/ovirt/README.rst +++ b/lib/ansible/modules/cloud/ovirt/README.rst @@ -47,7 +47,7 @@ New module development ---------------------- Please read -`link `__, +`link `__, first to know what common properties, functions and features every module must have. diff --git a/test/legacy/Makefile b/test/legacy/Makefile index 95806436cd8..1c04b4599d5 100644 --- a/test/legacy/Makefile +++ b/test/legacy/Makefile @@ -1,7 +1,7 @@ # This Makefile is for legacy integration tests. # Most new tests should be implemented using ansible-test. # Existing tests are slowly being migrated to ansible-test. -# See: https://docs.ansible.com/ansible/dev_guide/testing_integration.html +# See: https://docs.ansible.com/ansible/devel/dev_guide/testing_integration.html TEST_DIR ?= ~/ansible_testing INVENTORY ?= inventory