cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Change Shippable refs in docs to Azure Pipelines.

Browse source
This commit is contained in:
Matt Clay 2021-05-05 16:43:00 -07:00
parent c48f80d062
commit 8bd599d048
4 changed files with 11 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/docsite/rst/community/development_process.rst
View file

@ -37,7 +37,7 @@ Here's an overview of the PR lifecycle:
* Ansibot reviews the PR
* Ansibot assigns labels
* Ansibot pings maintainers
* Shippable runs the test suite
* Azure Pipelines runs the test suite
* Developers, maintainers, community review the PR
* Contributor addresses any feedback from reviewers
* Developers, maintainers, community re-review
@ -80,7 +80,7 @@ Ansibullbot runs continuously. You can generally expect to see changes to your i
- If the pull request is labeled **community_review** and the reviewer has not responded lately:
- The reviewer is first politely pinged after two weeks, pinged again after two more weeks and labeled **pending_action**, and then may be reassigned to ``$team_ansible`` or labeled **core_review**, or often the submitter of the pull request is asked to step up as a maintainer.
- If Shippable tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why.
- If Azure Pipelines tests fail, or if the code is not able to be merged, the pull request is automatically put into **needs_revision** along with a message to the submitter explaining why.
There are corner cases and frequent refinements, but this is the workflow in general.

2
docs/docsite/rst/dev_guide/developing_collections_testing.rst
View file

@ -15,7 +15,7 @@ Testing tools
The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing`. You can run several compile and sanity checks, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting.
You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Shippable both in the ansible/ansible GitHub repository and in the large community collections such as `community.general <https://github.com/ansible-collections/community.general/>`_ and `community.network <https://github.com/ansible-collections/community.network/>`_. The examples below demonstrate running tests in Docker containers.
You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Azure Pipelines both in the ansible/ansible GitHub repository and in the large community collections such as `community.general <https://github.com/ansible-collections/community.general/>`_ and `community.network <https://github.com/ansible-collections/community.network/>`_. The examples below demonstrate running tests in Docker containers.
Compile and sanity tests
------------------------

14
docs/docsite/rst/dev_guide/testing.rst
View file

@ -13,7 +13,7 @@ Why test your Ansible contributions?
If you're a developer, one of the most valuable things you can do is to look at GitHub issues and help fix bugs, since bug-fixing is almost always prioritized over feature development. Even for non-developers, helping to test pull requests for bug fixes and features is still immensely valuable.
Ansible users who understand how to write playbooks and roles should be able to test their work. GitHub pull requests will automatically run a variety of tests (for example, Shippable) that show bugs in action. However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged.
Ansible users who understand how to write playbooks and roles should be able to test their work. GitHub pull requests will automatically run a variety of tests (for example, Azure Pipelines) that show bugs in action. However, contributors must also test their work outside of the automated GitHub checks and show evidence of these tests in the PR to ensure that their work will be more likely to be reviewed and merged.
Read on to learn how Ansible is tested, how to test your contributions locally, and how to extend testing capabilities.
@ -51,16 +51,16 @@ able to add integration tests and so GitHub pull requests with integration tests
bugs in action will also be a great way to help.
Testing within GitHub & Shippable
=================================
Testing within GitHub & Azure Pipelines
=======================================
Organization
------------
When Pull Requests (PRs) are created they are tested using Shippable, a Continuous Integration (CI) tool. Results are shown at the end of every PR.
When Pull Requests (PRs) are created they are tested using Azure Pipelines, a Continuous Integration (CI) tool. Results are shown at the end of every PR.
When Shippable detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example::
When Azure Pipelines detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example::
The test `ansible-test sanity --test pep8` failed with the following errors:
@ -69,7 +69,7 @@ When Shippable detects an error and it can be linked back to a file that has bee
The test `ansible-test sanity --test validate-modules` failed with the following error:
lib/ansible/modules/network/foo/bar.py:0:0: E307 version_added should be 2.4. Currently 2.3
From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Shippable, for example:
From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Azure Pipelines, for example:
If you haven't already got Ansible available, use the local checkout by running::
@ -90,7 +90,7 @@ Occasionally you may find your PR fails due to a reason unrelated to your change
* a temporary issue accessing an external resource, such as a yum or git repo
* a timeout creating a virtual machine to run the tests on
If either of these issues appear to be the case, you can rerun the Shippable test by:
If either of these issues appear to be the case, you can rerun the Azure Pipelines test by:
* adding a comment with ``/rebuild`` (full rebuild) or ``/rebuild_failed`` (rebuild only failed CI nodes) to the PR
* closing and re-opening the PR (full rebuild)

2
docs/docsite/rst/dev_guide/testing_units_modules.rst
View file

@ -76,7 +76,7 @@ with integration tests, such as:
failures and exceptions
* Extensive testing of slow configuration APIs
* Situations where the integration tests cannot be run as part of the main Ansible
continuous integration running in Shippable.
continuous integration running in Azure Pipelines.