Workshops Home RHEL Network Security Windows Config as Code Open an Issue

Contribute

We treat Ansible Automation Workshops just like we treat the Ansible Project. Please help us! Check out the Issues for a list of what we are working on.

Table of Contents

Pull Requests

We take pull requests! What is a pull request?

Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch

More info on PRs: https://help.github.com/en/articles/about-pull-requests

Create a fork!

Create a fork on your own Github project (or your personal space)

Github Documentation on Forking a repo

Stay in Sync

It is important to know how to keep your fork in sync with the upstream Workshops project.

Configuring Your Remotes

Configure ansible/workshops as your upstream so you can stay in sync

git remote add upstream https://github.com/ansible/workshops.git

Rebasing Your Branch

Rebase the branch on your fork

git pull --rebase upstream devel

Check your status

git status

Updating your Pull Request

git push --force

More info on docs.ansible.com: Rebasing a Pull Request

Create a pull requests

PULL REQUESTS MUST BE MADE INTO THE DEVEL BRANCH

Make sure you are not behind (in sync) and then submit a PR to the Ansible Workshops.
Read the Pull Request Documentation on Github.com

Just because you submit a PR, doesn’t mean that it will get accepted. Right now the QA process is manual for Workshops, so provide detailed directions on

Being more descriptive is better, and has a higher change of getting merged upstream. Communication is key! Just b/c the PR doesn’t get accepted right away doesn’t mean it is not a good idea. Ansible Workshops have to balance many different types of users. Thank you for contributing!

Testing and Continuous Integration

Every Pull Requests submitted is expected to pass linters verification. (linters currently enabled: yamllint). If the PR is not passing tox -e linters it won’t be able to merge.

To verify locally, install tox and from within your ansible/workshops clone, run tox -e linters.

# pip install tox
# cd /path/to/workshops
# tox -e linters
linters installed: pathspec==0.6.0,PyYAML==5.1.2,yamllint==1.19.0
linters run-test-pre: PYTHONHASHSEED='2171258914'
linters runtests: commands[0] | yamllint -s .
___________________________________________________________________________________________ summary ___________________________________________________________________________________________
  linters: commands succeeded
  congratulations :)

To make sure this is run everytime one commits a change, and hence one is not sending a Pull Request that won’t be merged, one could enable this as part of a git pre-commit hook

Adding CI to a new workshop type

Two sides to CI (Continuous Integration).

  1. WORKSHOP SIDE: Example PR from Will Tome https://github.com/ansible/workshops/pull/1083

  2. CI SIDE

Yanis side PR to enable that workshop testing:

FAQ: I’m working on getting CI going to a new ansible workshop. Is it possible to exclude a directory from lint check?

Yanis Guenane: Yes - https://github.com/ansible/workshops/blob/devel/.yamllint#L4

Contributing New Workshop Types of content

Going Further

The following links will be helpful if you want to contribute code to the Ansible Workshops project, or any Ansible project:

Getting Help

Please file issues on Github. Please fill out all required information. Your issue will be closed if you skip required information in the Github issues template.

Ansible-Workshop-Logo.png