* clarify no subfolders and md only for collections /docs folder (#63808) (cherry picked from commit6a2902c8d5) * Fixed example error in windows_winrm user guide (#63922) The example code to configure TLS 1.2 Support using Ansible had an indention error. The register variable 'enable_tls12' was not indented. This caused the subsequent task to fail since the variable was not registered. (cherry picked from commitc562e17659) * Fix doc errors in AWS modules (#63851) * Fix register/debug in aws_batch_compute_environment * Fix aws_batch_job_queue doc errors * Fix module naming: `batch_job_queue` > `aws_batch_job_queue` * Fix missing register * Update debug task to use modern YAML format * Fix missing register + debug for lambda_policy * Fix YAML syntax for elb_application_lb_info module (cherry picked from commite4f16368ed) * Update documentation for package module (#63909) It is not clear from the documentation that list can be used (cherry picked from commit7f2c367d78) * [ec2_launch_template] Update description of state param (#63147) Currently, it is not possible to delete specific versions of an ec2 launch template. The module docs incorrectly suggest that there is a `version` param to the module that can be used to do that. This patch aims to correct that error. (cherry picked from commit7ea7260753) * template: Add a space in example block (#63930) (cherry picked from commitf279715c29) * revisions to docsite README (#63957) (cherry picked from commit5c962ef859) * combine galaxy.com install roles details (#63486) (cherry picked from commitee8a088205) * Correct a typo (#64020) (cherry picked from commit18f4f0549f) * Update password.py (#63965) Update the examples of the password lookup plugin to show how multiple options are joined together. (cherry picked from commit92daec5d0b) * Fix indentation of example (#63789) Remove no_log since module_defaults aren't displayed like set_fact was (cherry picked from commit1e52782d6b) * add newline to render table correctly (#63769) (cherry picked from commit1aee11c860) * clarified some points on environment keyword usage (#64065) (cherry picked from commit885ee62b53)
8.5 KiB
Ansible documentation
This project hosts the source behind docs.ansible.com.
To create clear, concise, consistent, useful materials on docs.ansible.com, please refer to the following information.
About Ansible
Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates. Learn more about Ansible here.
To install Ansible, see the Installation Guide.
The following sections provide information and resources on contributing to Ansible documentation.
Contributions
Ansible documentation is written in ReStructuredText(RST). Contributions to the documentation are welcome.
The Ansible community produces guidance on contributions, building documentation, and submitting pull requests, which you can find in Contributing to the Ansible Documentation.
Filing issues
If you do not want to learn the reStructuredText format, you can also [file issues] about documentation problems on the Ansible GitHub project.
Editing docs directly on GitHub
For typos and other quick fixes, you can edit the documentation right from the site. See Editing docs directly on GitHub for more information.
Ansible style guide
To create clear, concise, consistent, useful materials on docs.ansible.com, follow the guidelines found in the Ansible Style Guide.
reStructuredText
The Ansible style guide also includes useful guidelines on writing in reStructuredText. Please see the style guide for reStructuredText formatting guidelines for:
- header notation
- internal navigation
- linking
- local table of contents
Tools
The Ansible community provides resources on tools used to write, test, and build documentation. In this section you will find some helpful links and workflow recommendations to get started writing or editing documentation.
Popular editors
The Ansible community uses a range of tools for working with the Ansible project. Find a list of some of the most popular of these tools here.
Building documentation
Building the documentation is the best way to check for errors and review your changes. Ansible documentation is built using Sphinx. For resources on Sphinx and building documentation, see building the documentation locally in the Ansible Community Guide.
Github
Ansible documentation is hosted on the Ansible Github project.
The following sections describe the workflows required to start developing or submit changes to Ansible documentation.
Setting up Git
GitHub provides a set of Git cheatsheets in multiple languages.
-
First Install Git
-
Perform the initial Git setup tasks, as described in First Time Git Setup.
-
Navigate to https://github.com/ansible/ansible and create a fork. This will create your own version of the repository which you can find at https://github.com/{yourusername}/ansible where {yourusername} is the username you created in GitHub.
-
Clone from your fork to create a copy on your local machine.
NOTE: It is possible to clone using SSH so you don't have to enter a username/password every time you push. Find instructions at Connecting to GitHub with SSH and Which Remote URL Should I Use. When using SSH, the origin lines will appear like this:
git@github.com:{yourusername}/ansible.git
$ git clone git@github.com:{yourusername}/ansible.git
- Navigate to the new directory by entering the following from the command line on your local machine:
$ cd {repository-name}
- Add a git remote to your local repository to link to the upstream version of the documentation. This makes it easier to update your fork and local version of the documentation.
$ git remote add upstream git://github.com/ansible/ansible.git
- Check your settings.
$ git remote -v
origin https://github.com/{YOUR_USERNAME}/{YOUR_FORK}.git (fetch)
origin https://github.com/{YOUR_USERNAME}/{YOUR_FORK}.git (push)
upstream https://github.com/{ORIGINAL_OWNER}/{ORIGINAL_REPOSITORY}.git (fetch)
upstream https://github.com/{ORIGINAL_OWNER}/{ORIGINAL_REPOSITORY}.git (push)
Creating a topic branch
Create a topic branch for new documentation submissions or larger changes.
- Fetch updates from
origin:
$ git fetch origin
- Checkout a new branch based on
devel:
$ git checkout -b {branch name}
- Create new documents or make changes to existing files.
- Add new or changed files:
$ git add {file name}
- Commit your changes or additions. Be sure to include a commit message:
$ git commit -m "new message"
- Push your updates back to
origin:
$ git push -u origin {branch name}
Once you have completed this workflow, it is a good idea to build the documentation and ensure everything is correct and that it works. As a contributor, you are required to prove that See building the documentation locally in the Ansible Community Guide for more on building documentation.
When final additions or changes are pushed back to your fork you can open a pull request (PR).
Working with pull requests (PRs)
Pull requests represent the stage in a contribution where you are ready to submit your work for review and inclusion in the documentation. When a PR is opened, a reviewer will check the work and potentially open a dialog around your proposed changes. PRs should include specific information, which you can find in Opening a new issue and/or PR in the Ansible Community Guide.
Creating a pull request
- Navigate to your personal fork: https://github.com/{yourusername}/ansible
- Click Pull requests and then click New pull requests.
- Use the drop-down menus, set the base repository to the stable branch and set the head repository to your topic branch.
- Apply appropriate labels. Include backport and documentation.
- Fill in the PR summary using the following template:
##### SUMMARY
##### ISSUE TYPE
##### COMPONENT NAME
docs.ansible.com
##### ANSIBLE VERSION
##### ADDITIONAL INFORMATION
NOTE: If you put 'closes ' in the summary, ansible will automatically close the issue on merge.
- Click Create pull request.
A reviewer will evaluate your contribution. They may open a dialog around the PR and suggest revisions or, if the PR meets acceptance criteria, will merge it to the base branch.
Backporting a pull request
All Ansible PRs must be merged to the devel branch first. Most users may, however, use a prior stable branch. Evaluate your pull request to determine if it applies to a prior branch.
See Backporting merged PRs for a complete worklfow.
Other Git workflows
In addition to creating a pull request and backporting, other workflows exist to help keep your topic branches and pull requests up-to-date. See the Developer Guide on git rebase to learn more about rebasing a pull request.