Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closes #1124 - Add documentation for role developers #1186

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions docs/development/ROLES.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# Foreman Ansible Modules - Role Developer Documentation

Roles are an active area of development for this collection and community member contributions are highly encouraged! This file contains documentation for those who want to contribute Ansible Roles to the Collection. For general role development documentation, particularly if you are new to role development, see the [Ansible Galaxy Documentation](https://galaxy.ansible.com/docs/contributing/creating_role.html) on role development first.

## Documentation

Documentation is important. Each role needs to be well documented so that users can figure out how to use it. We provide a standard [Template](https://github.com/theforeman/foreman-ansible-modules/tree/develop/docs/development/ROLE_README_TEMPLATE.md) for the role documentation, which you can copy from `docs/development/ROLE_README_TEMPLATE.md` to `roles/${name_of_role}/README.md` before editing.

If your role supports any variable, then that variable needs to be documented with an explanation of how it affects the role behavior, what is the default value if any, and when is the variable required.

When writing documentation, it helps to put yourself in the shoes of an user who is new to this software and not make too many assumptions about what they should already know. In this regard, it is expected to include several example playbooks along with an explanation of how each is expected to behave.

Please have a look at existing role `README.me` files in the collection to get an idea of how this should look. Of course, if you see any room for improvement in the existing role documentation, please open a PR for it!

## Testing

Testing Roles is also important. Writing quality tests ensures that future changes to the role, or to the underlying modules, do not break functionality in unintended ways. Before getting started it is helpful to first read the developer documentation on [Testing](https://theforeman.github.io/foreman-ansible-modules/develop/testing.html#) for this collection.

Every role needs to have an integration test in the form of a playbook `tests/test_playbooks/${name_of_role}_role.yml`. You can look at the test playbook for an existing role in the collection to see an example of what this looks like.

CI does not test against a live instance; rather you are expected to record test fixtures from your own live instance and include them with the role. You can use [Forklift](https://github.com/theforeman/forklift) to quickly get up and running with a live virtual instance for testing. In some cases you may want to use a test instance with greater hardware resources available, if the role performs certain hardware intensive actions such as syncing large repositories.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For editablility and diff-ability i prefer a one sentence per line style.


You will need to configure your development environment to point to your live test instance by editing the file `tests/test_playbooks/vars/server.yml` (first copy it from the example `tests/test_playbooks/vars/server.yml.example` if necessary).

It is recommended to record the test fixtures against an uncofigured instance, so that the recorded fixtures will capture truly creating all necessary resources. You can ensure that your test instance is in this state before recording the fixtures by running `$ foreman-installer --reset-data`. This will drop and re-seed all databases and clear all synced content - do NOT run this on your production instance as you will lose ALL data!

Recording and running the tests requires an API doc fixture `tests/fixtures/apidoc/${name_of_role}_role.json`. This should typically just be a soft link to `katello.json` in the same directory. This fixture should be included with your pull request.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not always katello.


Finally, to record the fixtures, use `make record_${name_of_role}_role`. This will run your test playbook against your test instance, and record all API requests and responses. When it is finished running, add and commit the fixtures at `tests/test_playbooks/fixtures/${name_of_role}_role-*.yml`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is basically the same for roles and modules. Should we rather link it and not duplicate the text?


## Changelogs

Don't forget to add a changelog fragment about your role! This is simple to do, just have a look at any previous example such as [this one](https://github.com/theforeman/foreman-ansible-modules/blob/2045c5edef5792d3235eb5c2b234ef08e3fa96b3/changelogs/fragments/1097-content-rhel-role.yml) to see how it should look.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this applies to any kind of plugin/role.
Should we move it to a contributing section?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modules get automatic changelog entries right? Do the inventory plugins?

32 changes: 32 additions & 0 deletions docs/development/ROLE_README_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
theforeman.foreman.your_new_role
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that this strives for consistency.
But is it substantially different from what a-galaxy role init provides? Does it provide a README template?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can provide your own skeleton to reference (https://docs.ansible.com/ansible/latest/galaxy/dev_guide.html#using-a-custom-role-skeleton) which we could do to include this README and at least a tasks/main.yml. As most roles do use the common role variables and have a common structure with the examples etc. I do find myself copying other roles READMEs and editing (and always missing updating something when I do).

================================

This section should contain a basic explanation of what the role does and why the user might use it.

Role Variables
--------------

This role supports the [Common Role Variables](https://github.com/theforeman/foreman-ansible-modules/blob/develop/README.md#common-role-variables).

Role specific variables should be documented as below:

`foreman_variable_name`: Documentation of variable behavior and default if any. Ideally, keep it brief but do not assume that the user is an expert in the corresponding Katello/Foreman feature.

Example Playbooks
-----------------

Include a basic example playbook here, and explain what the playbook does when it is run.

```yaml
- hosts: localhost
roles:
- role: theforeman.foreman.your_new_role
vars:
foreman_server_url: https://foreman.example.com
foreman_username: "admin"
foreman_password: "changeme"
foreman_organization: "ACME"
foreman_variable_name: "some_value"
```

It is appreciated if you can include a few more examples here, along with an explanation of how each behaves. Many users will go straight to the examples, so having a few examples showing key differences in how the role can be used will be very helpful.