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.
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 on your own Github project (or your personal space)
Github Documentation on Forking a repo
It is important to know how to keep your fork in sync with the upstream Workshops project.
Configure ansible/workshops as your upstream so you can stay in sync
git remote add upstream https://github.com/ansible/workshops.gitRebase the branch on your fork
git pull --rebase upstream develCheck your status
git statusgit push --forceMore info on docs.ansible.com: Rebasing a Pull Request
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
- 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 improved the Ansible Workshops is the best practice for teaching or building workshops.
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!
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
Two sides to CI (Continuous Integration).
-
WORKSHOP SIDE: Example PR from Will Tome ansible#1083
-
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
The following links will be helpful if you want to contribute code to the Ansible Workshops project, or any Ansible project:
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.
