diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88207e9e..edcfe55b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,200 +1,3 @@ # Contributing -We follow [Ansible Code of Conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html) in all our contributions and interactions within this repository. - -If you are a committer, also refer to the [Ansible committer guidelines](https://docs.ansible.com/ansible/devel/community/committer_guidelines.html). - -## Issue tracker - -Whether you are looking for an opportunity to contribute or you found a bug and already know how to solve it, please go to the [issue tracker](https://github.com/ansible-collections/community.mysql/issues). -There you can find feature ideas to implement, reports about bugs to solve, or submit an issue to discuss your idea before implementing it which can help choose a right direction at the beginning of your work and potentially save a lot of time and effort. -Also somebody may already have started discussing or working on implementing the same or a similar idea, -so you can cooperate to create a better solution together. - -## Open pull requests - -Look through currently [open pull requests](https://github.com/ansible-collections/community.mysql/pulls). -You can help by reviewing them. Reviews help move pull requests to merge state. Some good pull requests cannot be merged only due to a lack of reviews. And it is always worth saying that good reviews are often more valuable than pull requests themselves. For more information how to provide a good review, refer to the [review checklist](REVIEW_CHECKLIST.md). - -Also, consider taking up a valuable, reviewed, but abandoned pull request which you could politely ask the original authors to complete yourself. - -## Discussions - -For open questions, broad suggestions, and other comments that will not typically fit in the scope of an issue or pull request, [discussions](https://github.com/ansible-collections/community.mysql/discussions) are available. That section provides a place to have a more open and informal conversation about any and all things related to this collection, included but not limited to future development plans, functionality explanations and feature proposals that are not yet fleshed out enough for an issue of their own. - -## Looking for an idea to implement - -First, see the paragraphs above. - -If you came up with a new feature, it is always worth creating an issue -before starting to write code to discuss the idea with the community first. -If you are going to implement the feature yourself, say it in the issue explicitly to avoid working in parallel with somebody else. - -## Step-by-step guide how to get into development quickly - -We assume that you use Linux as a work environment (you can use a virtual machine as well) and have `git` installed. - -1. If possible, make sure that you have installed and started `docker`. While you can also run tests without docker, this makes it a lot easier since you do not have to install the precise requirements, and tests are running properly isolated and in the exact same environments as in CI. You often can also use `podman` with the `docker` executable shim, so if you have that you probably do not need to install `docker`. - -2. Clone the [ansible-core](https://github.com/ansible/ansible) repository: -```bash -git clone https://github.com/ansible/ansible.git -``` - -Instead of installing ansible-core from source, you can also work with an already existing installation of Ansible, ansible-base or ansible-core. Simply skip steps 2 and 3 in that case. - -3. Go to the cloned repository and prepare the environment: -```bash -cd ansible && source hacking/env-setup -pip install -r requirements.txt -cd ~ -``` -4. Create the following directories in your home directory: -```bash -mkdir -p ~/ansible_collections/community/mysql -``` - -5. Fork the `community.mysql` repository through the GitHub web interface. - -6. Clone the forked repository from your profile to the created path: -```bash -git clone https://github.com/YOURACC/community.mysql.git ~/ansible_collections/community/mysql -``` - -If you prefer to use the SSH protocol: -```bash -git clone git@github.com:YOURACC/community.mysql.git ~/ansible_collections/community/mysql -``` - - -7. Go to your new cloned repository. -```bash -cd ~/ansible_collections/community/mysql -``` - -8. Be sure you are in the main branch: -```bash -git status -``` - -9. Show remotes. There should be the `origin` repository only: -```bash -git remote -v -``` - -10. Add the `upstream` repository: -```bash -git remote add upstream https://github.com/ansible-collections/community.mysql.git -``` - -11. Update your local `main` branch: -```bash -git fetch upstream -git rebase upstream/main -``` - -12. Create a branch for your changes: -```bash -git checkout -b name_of_my_branch -``` - -13. We recommend you start with writing integration tests if applicable. - -Note: If there are any difficulties with writing the tests or you are not sure if the case can be covered, feel free to skip this step. -If needed, other contributors can help you with it later. - -All integration tests are stored in `tests/integration/targets` subdirectories. -Go to the subdirectory containing the name of module you are going to change. -For example, if you are fixing the `mysql_user` module, its tests are in `tests/integration/targets/test_mysql_user/tasks`. - -The `main.yml` file holds test tasks and includes other test files. -Look for a suitable test file to integrate your tests or create and include a dedicated test file. -You can use one of the existing test files as a draft. - -When fixing a bug, write a task which reproduces the bug from the issue. - -Put the reported case in the tests, then run integration tests with the following command: -```bash -ansible-test integration test_mysql_user --docker -vvv -``` -If the tests do not want to run, first, check you complete step 3 of this guide. - -If the tests ran successfully, there are usually two possible outcomes: -a) If the bug has not appeared and the tests have passed successfully, ask the reporter to provide more details. The bug can be not a bug actually or can relate to a particular software version used or specifics of local environment configuration. - -b) The bug has appeared and the tests has failed as expected showing the reported symptoms. - -14. Fix the bug. - -15. Run `flake8` against a changed file. If it is `plugins/modules/mysql_user.py`: -```bash -flake8 plugins/modules/mysql_user.py -``` -It is worth installing and running `flake8` against the changed file(s) first. -It shows unused imports, which is not shown by sanity tests (see the next step), as well as other common issues. -Optionally, you can use the `--max-line-length=160` command-line argument. - -16. Run sanity tests: -```bash -ansible-test sanity plugins/modules/mysql_user.py --docker -``` -If they failed, look at the output carefully - it is usually very informative and helps to identify a problem line quickly. -Sanity failings usually relate to wrong code and documentation formatting. - -17. Run integration tests: -```bash -ansible-test integration test_mysql_user --docker -vvv -``` - -There are two possible outcomes: -a) They have failed. Look at the output of the command. -Fix the problem place in the code and run again. -Repeat the cycle until the tests pass. - -b) They have passed. Remember they failed originally? Our congratulations! You have fixed the bug. - -18. Commit your changes with an informative but short commit message: -```bash -git add /path/to/changed/file -git commit -m "mysql_user: fix crash when ..." -``` - -19. Push the branch to the `origin` (your fork): -```bash -git push origin name_of_my_branch -``` - -20. Go to the `upstream` (http://github.com/ansible-collections/community.mysql). - -21. Go to `Pull requests` tab and create a pull request. - -GitHub is tracking your fork, so it should see the new branch in it and automatically offer -to create a pull request. Sometimes GitHub does not do it and you should click the `New pull request` button yourself. -Then choose `compare across forks` under the `Compare changes` title. -Choose your repository and the new branch you pushed in the right drop-down list. -Confirm. Fill out the pull request template with all information you want to mention. -Put "Fixes + link to the issue" in the pull request's description. -Put "[WIP] + short description" in the pull request's title. It's often a good idea to mention the name of the module/plugin you are modifying at the beginning of the description. -Click `Create pull request`. - -22. Add a [changelog fragment](https://docs.ansible.com/ansible/devel/community/development_process.html#changelogs) to the `changelog/fragments` directory. It will be published in release notes, so users will know about the fix. - -Commit and push it: -```bash -git add changelog/fragments/myfragment.yml -git commit -m "Add changelog fragment" -git push origin name_of_my_branch -``` - -23. The CI tests will run automatically on Red Hat infrastructure after every commit. - -You will see the CI status in the bottom of your pull request. -If they are green, remove "[WIP]" from the title. Mention the issue reporter in a comment and let contributors know that the pull request is "Ready for review". - -24. Wait for reviews. You can also ask for review on IRC in the #ansible-community channel. - -25. If the pull request looks good to the community, committers will merge it. - -For details, refer to the [Ansible developer guide](https://docs.ansible.com/ansible/latest/dev_guide/index.html). - -If you find any inconsistencies or places in this document which can be improved, feel free to raise an issue or pull request to fix it. +Refer to the [Ansible Contributing guidelines](https://github.com/ansible/community-docs/blob/main/contributing.rst) to learn how to contribute to this collection. diff --git a/CONTRIBUTORS b/CONTRIBUTORS new file mode 100644 index 00000000..7678773a --- /dev/null +++ b/CONTRIBUTORS @@ -0,0 +1,273 @@ +116davinder +20 +28 +29 +4 +4n70w4 +abadger +abondis +acozine +adamchainz +adq +Akasurde +Alexander198961 +alustenberg +aminvakil +amitk79 +amree +Andersson007 +andrewhowdencom +ansibot +anthonyxpalermo +antonioribeiro +apollo13 +aquach +arcmop +asad-at-srt +AshDevilRed +aurimasl +axelll +axisK +azielke +baldpale +banyek +BarbzYHOOL +Berbe +bjne +bmalynovytch +bmildren +boreal321 +brutus +burner1024 +calfonso +candeira +caphrim007 +cdalbergue +checkphi +chrismeyersfsu +ChristopherGAndrews +cmodijk +codeaken +codebymikey +coreylane +CormacBracken +cosmix +cptMikky +crashes +dagwieers +damianmoore +Davidffry +denisemauldin +diclophis +d-lee +dmp1ce +dnelson +dramaley +drybjed +drzraf +DSpeichert +dungdm93 +dwagelaar +dylanjbarth +einarc +E-M +eowin +Ernest0x +esamattis +Everspace +F21 +faitno +felixfontein +flatrocks +fourjay +fraff +g00fy- +geerlingguy +georgeOsdDev +ghjm +ghost +giacmir +giorgio-v +gkoller +gottwald +gstorme +gundalow +hansbaer +hchargois +hluaces +hwali +hyperfocus1338 +igormukhingmailcom +imjoseangel +infigoKriti +ipergenitsa +iredmail +ivandigiusto +jadbaz +jaikdean +jamescassell +janosmiko +jarnold-timeout +JaSafieddine +jborean93 +jctanner +jean-christophe-manciot +Jean-Daniel +jgornick +jhagg +jhoekx +jirib +jkleckner +jkordish +jlaska +Jmainguy +jochu +JoelFeiner +johnavp1989 +jonatasbaldin +Jorge-Rodriguez +jpjaatin +jpmens +JSafieddine +jsmartin +juergenhoetzel +jw34 +kalaisubbiah +kenichi-ogawa-1988 +kkeane +klingac +kotso +kuntalFreshBooks +kurtdavis +larsks +ldesgrange +leeadh +LeonB +leucos +loomsen +lorin +lowwalker +lperezs +makmanalp +manuelmorena +MarcinOrlowski +markdorison +markotitel +marktheunissen +markuman +mattclay +matt-horwood-mayden +mavimo +maxamillion +maxbube +mcgoldrickm +meanstrong +meersjo +megamisan +michaeldg +michalmedvecky +MikeiLL +milky-milk +milosz +mistaka0s +mklassen +mkrizek +mmoya +mohag +mohsenSy +mpdehaan +MRwangyd +mverwijs +mvgrimes +mysqlbox +netmonk +nhojpatrick +nicolas-g +NielsH +nitinkansal1984 +nitzmahone +Ompragash +on +order +organman91 +p53 +pakal +paulbadcock +pennycoders +petoju +petracvv +pgrenaud +philfry +pileofrogs +pkaramol +platypus-geek +plumbeo +pratikgadiya12 +pshanbhag +r0bj +rajsshah86 +reduzent +relrod +resmo +ricco24 +richlv +riupie +rndmh3ro +robertdebock +robpblake +rokka-n +Roxyrob +roysmith +rthouvenin +ruudk +samccann +samdoran +sayap +scottbrown +seanorama +sedrubal +sergey-trukhin +Shaps +shrikeh +sivel +skalfyfan +skoriy88 +sperantus +spoyd +steverweber +steveteahan +stijnopheide +stintel +stoned +strixBE +SWADESNA +tapologo +tejatsk14 +tersmitten +the +the02 +thomasliddledba +time-palominodb +timorunge +Tomasthanes +tomdymond +Tronde +tvlooy +tyll +UncertaintyP +vamshi8 +vanne +vdboor +vmahadev +v-zhuravlev +webmat +wedi +whysthatso +willthames +windowsansiblernew +wrosario +xiata +Xyon +yangchao0512 +ziegenberg +Zverik diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100644 index 00000000..c5205389 --- /dev/null +++ b/MAINTAINERS @@ -0,0 +1,3 @@ +bmalynovytch +Jorge-Rodriguez +Andersson007 (andersson007_ in #ansible-community IRC) diff --git a/MAINTAINING.md b/MAINTAINING.md new file mode 100644 index 00000000..9fad0d34 --- /dev/null +++ b/MAINTAINING.md @@ -0,0 +1,3 @@ +# Maintaining this collection + +Refer to the [Maintainer guidelines](https://github.com/ansible/community-docs/blob/main/maintaining.rst). diff --git a/README.md b/README.md index b1bd9d20..8d1349eb 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,46 @@ # MySQL collection for Ansible [![Plugins CI](https://github.com/ansible-collections/community.mysql/workflows/Plugins%20CI/badge.svg?event=push)](https://github.com/ansible-collections/community.mysql/actions?query=workflow%3A"Plugins+CI") [![Roles CI](https://github.com/ansible-collections/community.mysql/workflows/Roles%20CI/badge.svg?event=push)](https://github.com/ansible-collections/community.mysql/actions?query=workflow%3A"Roles+CI") [![Codecov](https://img.shields.io/codecov/c/github/ansible-collections/community.mysql)](https://codecov.io/gh/ansible-collections/community.mysql) +This collection is a part of the Ansible package. + +## Code of Conduct + +We follow the [Ansible Code of Conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html) in all our interactions within this project. + +If you encounter abusive behavior violating the [Ansible Code of Conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html), please refer to the [policy violations](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html#policy-violations) section of the Code of Conduct for information on how to raise a complaint. + +## Contributing + +The content of this collection is made by [people](https://github.com/ansible-collections/community.mysql/blob/main/CONTRIBUTORS) just like you, a community of individuals collaborating on making the world better through developing automation software. + +We are actively accepting new contributors. + +Any kind of contribution is very welcome. + +You don't know how to start? Refer to our [contribution guide](https://github.com/ansible-collections/community.mysql/blob/main/CONTRIBUTING.md)! + +## Collection maintenance + +The current maintainers (contributors with `write` or higher access) are listed in the [MAINTAINERS](https://github.com/ansible-collections/community.mysql/blob/main/MAINTAINERS) file. If you have questions or need help, feel free to mention them in the proposals. + +To learn how to maintain / become a maintainer of this collection, refer to the [Maintainer guidelines](https://github.com/ansible-collections/community.mysql/blob/main/MAINTAINING.md). + +## Communication + +We announce releases and important changes through Ansible's [The Bullhorn newsletter](https://eepurl.com/gZmiEP). Be sure you are subscribed. + +Join us in the `#ansible` (general use questions and support), `#ansible-community` (community and collection development questions), and other [IRC channels](https://docs.ansible.com/ansible/devel/community/communication.html#irc-channels) on [Libera.Chat](https://libera.chat). + +We take part in the global quarterly [Ansible Contributor Summit](https://github.com/ansible/community/wiki/Contributor-Summit) virtually or in-person. Track [The Bullhorn newsletter](https://eepurl.com/gZmiEP) and join us. + +For more information about communication, refer to the [Ansible Communication guide](https://docs.ansible.com/ansible/devel/community/communication.html). + +## Governance + +The process of decision making in this collection is based on discussing and finding consensus among participants. + +Every voice is important and every idea is valuable. If you have something on your mind, create an issue or dedicated discussion and let's discuss it! + ## Included content - **Modules**: @@ -20,7 +60,7 @@ ## External requirements -The MySQL modules rely on a MySQL connector. The list of supported drivers is below: +The MySQL modules rely on a MySQL connector. The list of supported drivers is below: - [PyMySQL](https://github.com/PyMySQL/PyMySQL) - [MySQLdb](https://github.com/PyMySQL/mysqlclient-python) @@ -44,11 +84,19 @@ collections: - name: community.mysql ``` -See [Ansible Using collections](https://docs.ansible.com/ansible/latest/user_guide/collections_using.html) for more details. +Note that if you install the collection from Ansible Galaxy, it will not be upgraded automatically if you upgrade the Ansible package. To upgrade the collection to the latest available version, run the following command: -## Contributing +```bash +ansible-galaxy collection install community.mysql --upgrade +``` -See the [contribution guide](CONTRIBUTING.md). +You can also install a specific version of the collection, for example, if you need to downgrade when something is broken in the latest version (please report an issue in this repository). Use the following syntax: + +```bash +ansible-galaxy collection install community.mysql:==2.0.0 +``` + +See [Ansible Using collections](https://docs.ansible.com/ansible/latest/user_guide/collections_using.html) for more details. ## Licensing diff --git a/REVIEW_CHECKLIST.md b/REVIEW_CHECKLIST.md index 3ea34401..9dccf7ef 100644 --- a/REVIEW_CHECKLIST.md +++ b/REVIEW_CHECKLIST.md @@ -1,38 +1,3 @@ # Review Checklist -When reviewing, keep in mind that we follow [Ansible Code of Conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html) in all our contributions and interactions within this repository. - -If you are a committer, also refer to the [Ansible committer guidelines](https://docs.ansible.com/ansible/devel/community/committer_guidelines.html). - -**General tips** -- Try to create a culture of collaboration when reviewing -- Welcome the author and thank them for the pull request -- When suggesting changes, try to use questions, not statements -- When suggesting mandatory changes, do it as politely as possible providing documentation references -- If your suggestion is optional or a matter of personal preferences, please say it explicitly -- When asking for adding tests or for complex code refactoring, say that the author is welcome to ask for clarifications and help if they need -- If somebody suggests a good idea, mention it or put a thumbs up -- After merging, thank the author and reviewers for their time and effort - -**Standards and documentation** -- [ ] if the pull request is not a documentation fix, it must include a [changelog fragment](https://docs.ansible.com/ansible/devel/community/development_process.html#creating-a-changelog-fragment) - please check the format carefully -- [ ] if new files are added with the pull request, they follow the [licensing rules](https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#licensing) -- [ ] the changes follow the [Ansible documentation standards](https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_documenting.html) and the [style guide](https://docs.ansible.com/ansible/devel/dev_guide/style_guide/index.html#style-guide) -- [ ] the changes follow the [development conventions](https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html) -- [ ] if a new plugin is added, it is one of the [allowed plugin types](https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#modules-plugins) -- [ ] documentation, examples, and return sections use FQCNs for the `M(..)` [format macros](https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_documenting.html#linking-and-other-format-macros-within-module-documentation) when referring to modules -- [ ] modules and plugins from ansible-core use `ansible.builtin.` as a FQCN prefix when mentioned -- [ ] when a new option, module, plugin, or return value is added, the corresponding documentation or return sections use `version_added:` containing the *collection* version which they will be first released in - * this usually is the next minor release, sometimes the next major release (example: if 2.7.5 is the current release, the next minor release will be 2.8.0, and the next major release will be 3.0.0) -- [ ] FQCNs are used for `extends_documentation_fragment:`, unless the author is referring to doc_fragments from ansible-core - -**Tests (if applicable and technically possible to implement)** -- [ ] the pull request has [integration tests](https://docs.ansible.com/ansible/devel/dev_guide/testing_integration.html) -- [ ] the pull request has [unit tests](https://docs.ansible.com/ansible/devel/dev_guide/testing_units.html) -- [ ] all changes are covered -- [ ] integration tests also cover `check_mode` (if it is supported) -- [ ] integration tests check an actual state of the system, not only what the module reports (for example, if the module changes a file, check that the file was actually changed by using the `ansible.builtin.stat` module) - -**Other** -- [ ] the pull request does not contain merge commits (see GitHub warnings at the bottom of the pull request) - in this case, ask the author to rebase the pull request branch -- [ ] if the pull request contains breaking changes, ask the author and the collection maintainers if it is really needed and there is no way not to introduce them +Refer to the [Collection review checklist](https://github.com/ansible/community-docs/blob/main/review_checklist.rst). diff --git a/plugins/doc_fragments/mysql.py b/plugins/doc_fragments/mysql.py index 6d7a5468..b7a91529 100644 --- a/plugins/doc_fragments/mysql.py +++ b/plugins/doc_fragments/mysql.py @@ -67,7 +67,7 @@ class ModuleDocFragment(object): - Whether to validate the server host name when an SSL connection is required. Corresponds to MySQL CLIs C(--ssl) switch. - Setting this to C(false) disables hostname verification. Use with caution. - Requires pymysql >= 0.7.11. - - This optoin has no effect on MySQLdb. + - This option has no effect on MySQLdb. type: bool version_added: '1.1.0' requirements: diff --git a/plugins/modules/mysql_user.py b/plugins/modules/mysql_user.py index b39b11a1..38c1a556 100644 --- a/plugins/modules/mysql_user.py +++ b/plugins/modules/mysql_user.py @@ -53,6 +53,7 @@ the module will always report changes. It includes grouping columns by permission (C(SELECT(col1,col2)) instead of C(SELECT(col1),SELECT(col2))). - Can be passed as a dictionary (see the examples). + - Supports GRANTs for procedures and functions (see the examples). type: raw append_privs: description: @@ -188,6 +189,15 @@ 'db1.*': 'ALL,GRANT' 'db2.*': 'ALL,GRANT' +# Use 'PROCEDURE' instead of 'FUNCTION' to apply GRANTs for a MySQL procedure instead. +- name: Grant a user the right to execute a function + community.mysql.mysql_user: + name: readonly + password: 12345 + priv: + FUNCTION my_db.my_function: EXECUTE + state: present + # Note that REQUIRESSL is a special privilege that should only apply to *.* by itself. # Setting this privilege in this manner is deprecated. # Use 'tls_requires' instead.