Codecov Report

Merging#1875 (1339d64) intomain (5370979) willincrease coverage by0.00%.
The diff coverage is96.15%.

@@           Coverage Diff           @@##             main    #1875   +/-   ##=======================================  Coverage   92.56%   92.57%           =======================================  Files          78       78             Lines        4910     4930   +20     =======================================+ Hits         4545     4564   +19- Misses        365      366    +1

Flags with carried forward coverage won't be shown.Click here to find out more.

Example program using this:

$ cat show-it.py#!/usr/bin/python3 -ttuimport gitlabgl = gitlab.Gitlab(url="https://gitlab.com")project = gl.projects.get("gitlab-org/gitlab")mrs = project.mergerequests.list(state="opened")

Run of program:

$ ./show-it.py..././show-it.py:7: UserWarning: Calling a `list()` method without specifying `all=True` or `as_list=False` will return a maximum of 20 items. Your query returned 20 of 1286 items. See https://python-gitlab.readthedocs.io/en/v3.1.1/api-usage.html#pagination for more details. If this was done intentionally, then this warning can be supressed by adding the argument `page=1` or `get_all=False` to the `list()` call.  mrs = project.mergerequests.list(state="opened")

Finally had a look around and here's some more valid use cases where we don't want to emit warnings on this - essentially whenever any kind of list filter is applied, I'd say. In those cases users mostly only care about the first item.

1. Getting a user by username (can't use the GET endpoint):https://github.com/ansible-collections/community.general/blob/21ee4c84b7da0f5f540882b6d035c47da473db1f/plugins/modules/source_control/gitlab/gitlab_user.py#L521-L525
2. Get group/project via loose name search:https://github.com/ansible-collections/community.general/blob/21ee4c84b7da0f5f540882b6d035c47da473db1f/plugins/modules/source_control/gitlab/gitlab_group_members.py#L180-L190
3. Checking for existence of items:https://github.com/ansible-collections/community.general/blob/21ee4c84b7da0f5f540882b6d035c47da473db1f/plugins/modules/source_control/gitlab/gitlab_group.py#L282-L284

Answering without doing a lot of research on these:

Finally had a look around and here's some more valid use cases where we don't want to emit warnings on this - essentially whenever any kind of list filter is applied, I'd say. In those cases users mostly only care about the first item.

1. Getting a user by username (can't use the GET endpoint):https://github.com/ansible-collections/community.general/blob/21ee4c84b7da0f5f540882b6d035c47da473db1f/plugins/modules/source_control/gitlab/gitlab_user.py#L521-L525

Warning will not be issued unless for some reason 20 items are returned by thelist() call. In that case it is likely highlighting a real error. I have submitted a PR that adds aall=True for this.

2. Get group/project via loose name search:https://github.com/ansible-collections/community.general/blob/21ee4c84b7da0f5f540882b6d035c47da473db1f/plugins/modules/source_control/gitlab/gitlab_group_members.py#L180-L190

Warning will not be issued unless for some reason 20 items are returned by thelist() call. In that case it is likely highlighting a real error. I have submitted a PR that adds aall=True for this.

3. Checking for existence of items:https://github.com/ansible-collections/community.general/blob/21ee4c84b7da0f5f540882b6d035c47da473db1f/plugins/modules/source_control/gitlab/gitlab_group.py#L282-L284

Yes a warning has a good chance of being produced for this one. I have submitted a PR that adds aall=False for this.

ansible-collections/community.general#4491

Thanks for this@JohnVillalovos! Took a while as I am really uneasy about eagerly sending warnings but this will definitely reduce the issues filed.

Thanks@nejch ! I'm interested to see feedback on it once it starts getting used by people. I know when I tried it on my code I found spots where I was like "whoops!".