* Suggest ansible ad-hoc command while developing module (#70308) If a local module has no documentation, the doc command will fail without any hints of what is wrong. Add another way to confirm the presence of a local module. * Update docs/docsite/rst/dev_guide/developing_locally.rst Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com> (cherry picked from commit82e5d03bdb
) * Update AWS Integration test docmentation (#70454) (cherry picked from commite1ba7dc52a
) * Update hacking/shippable docs. The `--all` option downloads more than is needed for analyzing code coverage. (cherry picked from commitfb7740ae3b
) * Document that subversion module requires subversion (#70537) (cherry picked from commit64c2cb273f
) * update documentation link to python 3 (#70509) update the docs link for strftime on the filters page to point to the python3 docs (cherry picked from commitf7db428375
) * Update windows_winrm.rst (#70306) gcc also needed to be installed alongside python-devel, krb5-devel, krb5-libs, and krb5-workstation. (cherry picked from commitf4ea43c4a0
) * updated requirements file for docs build (#70609) (cherry picked from commit38ccfb4a3e
) * Clarify that index_var is 0 indexed (#70548) A little further down the page is another index, ansible_loop.index, which shares a similar description but is 1 indexed. Its zero indexed twin has a 0 suffix. ``ansible_loop.index`` The current iteration of the loop. (1 indexed) ``ansible_loop.index0`` The current iteration of the loop. (0 indexed) To remove ambiguity around the usage of index_var, explicitly mention that this variable is 0 indexed. (cherry picked from commitc410311f55
) * docs: update module development docs (#70594) Update module development docs for flattened modules directory. Fixes: #70261 (at least partially) Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com> (cherry picked from commit20209c508f
) * Doc: fix examples of changelog entries. (#70551) (cherry picked from commitedcd1a1a70
) * Document tags are not supported with task meta. (#70590) fixes #70338 (cherry picked from commit40591d5fbb
) * docs: update date format in removed_at_date (#70597) removed_at_date requires YYYY-MM-DD format. Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com> (cherry picked from commit375c6b4ae4
) * partial update of community docs to reflect collections transition (#70488) (cherry picked from commitf1f782fc37
) Co-authored-by: Michael Ritsema <michaelritsema@users.noreply.github.com> Co-authored-by: Mark Chappell <mchappel@redhat.com> Co-authored-by: Matt Clay <matt@mystile.com> Co-authored-by: Alan Rominger <arominge@redhat.com> Co-authored-by: FloMiau <37121807+FloMiau@users.noreply.github.com> Co-authored-by: mahadelmi <mahadelmi@cmail.carleton.ca> Co-authored-by: Sayee <57951841+sayee-jadhav@users.noreply.github.com> Co-authored-by: Karl Goetz <goetzk@users.noreply.github.com> Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com> Co-authored-by: Andrew Klychkov <aaklychkov@mail.ru> Co-authored-by: Baptiste Mille-Mathias <baptiste.millemathias@gmail.com> Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>
6 KiB
Shippable Scripts
Scripts
This directory contains the following scripts:
- download.py - Download results from Shippable.
- get_recent_coverage_runs.py - Retrieve Shippable URLs of recent coverage test runs.
- incidental.py - Report on incidental code coverage using data from Shippable.
- run.py - Start new runs on Shippable.
Incidental Code Coverage
Background
Incidental testing and code coverage occurs when a test covers one or more portions of code as an unintentional side-effect of testing another portion of code.
For example, the yum
integration test intentionally tests the yum
Ansible module.
However, in doing so it also uses, and unintentionally tests the file
module as well.
As part of the process of migrating modules and plugins into collections, integration tests were identified that provided exclusive incidental code coverage. That is, tests which would be migrated out of the repository which covered code which would not be covered by any remaining tests.
These integration test targets were preserved as incidental tests with the incidental_
prefix prior to migration.
The plugins necessary to support these tests were also preserved in the test/support/
directory.
The long-term goal for these incidental tests is to replace them with tests that intentionally cover the relevant code. As additional intentional tests are added, the exclusive coverage provided by incidental tests will decline, permitting them to be removed without loss of test coverage.
Reducing Incidental Coverage
Reducing incidental test coverage, and eventually removing incidental tests involves the following process:
- Run the entire test suite with code coverage enabled.
This is done automatically each day on Shippable.
The URLs and statuses of the most recent such test runs can be found with:
The branch name defaults tohacking/shippable/get_recent_coverage_runs.py <optional branch name>
devel
. - Download code coverage data from Shippable for local analysis.
Example:
# download results to ansible/ansible directory under cwd # substitute the correct run number for the Shippable coverage run you want to download hacking/shippable/download.py https://app.shippable.com/github/ansible/ansible/runs/162160 --test-results --run-metadata -v
- Analyze code coverage data to see which portions of the code are covered by each test.
Example:
# make sure ansible-test is in $PATH source hacking/env-setup # run the script using whichever directory results were downloaded into hacking/shippable/incidental.py ansible/ansible/162160
- Create new intentional tests, or extend existing ones, to cover code that is currently covered by incidental tests.
Reports are created by default in a
test/results/.tmp/incidental/{hash}/reports/
directory. The{hash}
value is based on the input files used to generate the report.
Over time, as the above process is repeated, exclusive incidental code coverage will decline. When incidental tests no longer provide exclusive coverage they can be removed.
CAUTION: Only one incidental test should be removed at a time, as doing so may cause another test to gain exclusive incidental coverage.
Incidental Plugin Coverage
Incidental test coverage is not limited to incidental_
prefixed tests.
For example, incomplete code coverage from a filter plugin's own tests may be covered by an unrelated test.
The incidental.py
script can be used to identify these gaps as well.
Follow the steps 1 and 2 as outlined in the previous section.
For step 3, add the --plugin-path {path_to_plugin}
option.
Repeat step 3 for as many plugins as desired.
To report on multiple plugins at once, such as all filter
plugins, the following command can be used:
find lib/ansible/plugins/filter -name '*.py' -not -name __init__.py -exec hacking/shippable/incidental.py ansible/ansible/162160 --plugin-path '{}' ';'
Each report will show the incidental code coverage missing from the plugin's own tests.
NOTE: The report does not identify where the incidental coverage comes from.
Reading Incidental Coverage Reports
Each line of code covered will be included in a report. The left column contains the line number where the source occurs. If the coverage is for Python code a comment on the right side will indicate the coverage arcs involved.
Below is an example of a report:
Target: incidental_win_psexec
GitHub: https://github.com/ansible/ansible/blob/6994ef0b554a816f02e0771cb14341a421f7cead/test/integration/targets/incidental_win_psexec
Source: lib/ansible/executor/task_executor.py (2 arcs, 3/1141 lines):
GitHub: https://github.com/ansible/ansible/blob/6994ef0b554a816f02e0771cb14341a421f7cead/lib/ansible/executor/task_executor.py
705 if 'rc' in result and result['rc'] not in [0, "0"]: ### (here) -> 706
706 result['failed'] = True ### 705 -> (here) ### (here) -> 711
711 if self._task.until: ### 706 -> (here)
The report indicates the test target responsible for the coverage and provides a link to the source on GitHub using the appropriate commit to match the code coverage.
Each file covered in the report indicates the lines affected, and in the case of Python code, arcs. A link to the source file on GitHub using the appropriate commit is also included.
The left column includes the line number for the source code found to the right. In the case of Python files, the rightmost comment indicates the coverage arcs involved.
### (here) -> 706
for source line 705 indicates that execution flowed from line 705 to line 706.
Multiple outbound line numbers can be present.
### 706 -> (here)
for source line 711 indicates that execution flowed from line 706 to line 711.
Multiple inbound line numbers can be present.
In both cases (here)
is simply a reference to the current source line.
Arcs are only available for Python code. PowerShell code only reports covered line numbers.