Contribute

Please help us! Check out the Issues for a list of what we are working on.

Table of Contents

• Pull Requests
  • Create a fork!
  • Stay in Sync
    • Configuring Your Remotes
    • Rebasing Your Branch
    • Updating your Pull Request
  • Create a pull requests
  • Testing and Continuous Integration
• Contributing New Workshop Types of content
• Going Further

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

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.
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

• WHY? Why did you make the change?
• WHO? Who is this for? If this is something for a limited audience it might not make sense for all users.
• BEST PRACTICE? Is this the “best” way to do this? Link to documentation or examples where the way you solved your issue or improve the content.

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 local clone, run tox -e linters.

# pip install tox
# cd /path/to/workshop
# 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

Contributing content

• Contrbitue New Workshop Exercises

Going Further

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

• Learning Git