internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: ansible-collections/community.general

Issue:
generic `file` options not all applicable to any module 
### Summary

The `filesize` module documentation online https://docs.ansible.com/ansible/latest/collections/community/general/filesize_module.html claims that it supports `unsafe_writes` option, that is currently not the case, and will never be, due to the purpose of the module (create, truncate or grow a file, in place).

This `unsafe_writes` option has been automatically added, as a result of module's DOCUMENTATION:
```
extends_documentation_fragments:
  - ansible.builtin.files
```
The module supports other options that are related to file ***properties*** (e.g. `group`, `owner`, `mode`, `attributes`), but `unsafe_writes` has nothing to do with such *static* metadata, but with the *process* of modifying a file instead, and this process is not handled by the `filesize` module in a way that could let a choice to the user.

Is the `extends_documentation_fragments` an all-or-nothing, or is there some way to get more granularity, and skip/hide unsupported options ?

### Issue Type

Documentation Report

### Component Name

filesize

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:
Files identified in the description:
* [`plugins/modules/files/filesize.py`](https://github.com/ansible-collections/community.general/blob/master/plugins/modules/files/filesize.py)

If these files are inaccurate, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
It's unfortunately all-or-nothing. What you can do though is overwrite descriptions from doc fragments. So it could be replaced by `This option is not used by this module.`.
@quidame: Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:
- ansible version

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE/bug_report.md

[click here for bot help](https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md)
<!--- boilerplate: issue_missing_data --->

Resolving patch:
diff --git a/plugins/modules/files/filesize.py b/plugins/modules/files/filesize.py
--- a/plugins/modules/files/filesize.py
+++ b/plugins/modules/files/filesize.py
@@ -87,6 +87,10 @@
       - I(force=true) and I(sparse=true) are mutually exclusive.
     type: bool
     default: false
+  unsafe_writes:
+    description:
+      - This option is silently ignored. This module always modifies file
+        size in-place.
 
 notes:
   - This module supports C(check_mode) and C(diff).


Test patch:
Repository: ansible-collections/community.general

Issue:
Include sensor Status property when querying chassis thermal properties via Redfish
### Summary

Currently `get_chassis_thermals()` in `redfish_utils.py` [does not include the Sensor "Status" property](https://github.com/ansible-collections/community.general/blob/771e9de010b2c4cb256f5fe2a9375d63e6eac511/plugins/module_utils/redfish_utils.py#L1884-L1890).

As per DSP2046, items in the "Temperatures" array should include a Status object [as per Redfish 2016.2](https://www.dmtf.org/sites/default/files/standards/documents/DSP2046_2016.2.pdf).

This Status property is used for reporting on the state/status/health/presence of Thermal sensors.



cc @sylgeist 

### Issue Type

Feature Idea

### Component Name

redfish_utils.py

### Additional Information

<!--- Paste example playbooks or commands between quotes below -->
```yaml (paste below)

```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:

Resolving patch:
diff --git a/plugins/module_utils/redfish_utils.py b/plugins/module_utils/redfish_utils.py
--- a/plugins/module_utils/redfish_utils.py
+++ b/plugins/module_utils/redfish_utils.py
@@ -1887,7 +1887,7 @@ def get_chassis_thermals(self):
                       'LowerThresholdCritical', 'LowerThresholdFatal',
                       'LowerThresholdNonCritical', 'MaxReadingRangeTemp',
                       'MinReadingRangeTemp', 'ReadingCelsius', 'RelatedItem',
-                      'SensorNumber']
+                      'SensorNumber', 'Status']
 
         # Go through list
         for chassis_uri in self.chassis_uris:


Test patch:
Repository: ansible-collections/community.general

Issue:
Include sensor Status property when querying chassis thermal properties via Redfish
### Summary

Currently `get_chassis_thermals()` in `redfish_utils.py` [does not include the Sensor "Status" property](https://github.com/ansible-collections/community.general/blob/771e9de010b2c4cb256f5fe2a9375d63e6eac511/plugins/module_utils/redfish_utils.py#L1884-L1890).

As per DSP2046, items in the "Temperatures" array should include a Status object [as per Redfish 2016.2](https://www.dmtf.org/sites/default/files/standards/documents/DSP2046_2016.2.pdf).

This Status property is used for reporting on the state/status/health/presence of Thermal sensors.



cc @sylgeist 

### Issue Type

Feature Idea

### Component Name

redfish_utils.py

### Additional Information

<!--- Paste example playbooks or commands between quotes below -->
```yaml (paste below)

```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:
Files identified in the description:
* [`plugins/modules/remote_management/redfish/redfish_command.py`](https://github.com/ansible-collections/community.general/blob/master/plugins/modules/remote_management/redfish/redfish_command.py)
* [`plugins/modules/remote_management/redfish/redfish_config.py`](https://github.com/ansible-collections/community.general/blob/master/plugins/modules/remote_management/redfish/redfish_config.py)
* [`plugins/modules/remote_management/redfish/redfish_info.py`](https://github.com/ansible-collections/community.general/blob/master/plugins/modules/remote_management/redfish/redfish_info.py)

If these files are inaccurate, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
cc @mraineri @renxulei @tomasg2012 @xmadsen
[click here for bot help](https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md)
<!--- boilerplate: notify --->
PR for this feature: #3233 
Thanks for the suggestion and pull request; certainly useful info to extract.

Resolving patch:
diff --git a/plugins/module_utils/redfish_utils.py b/plugins/module_utils/redfish_utils.py
--- a/plugins/module_utils/redfish_utils.py
+++ b/plugins/module_utils/redfish_utils.py
@@ -1887,7 +1887,7 @@ def get_chassis_thermals(self):
                       'LowerThresholdCritical', 'LowerThresholdFatal',
                       'LowerThresholdNonCritical', 'MaxReadingRangeTemp',
                       'MinReadingRangeTemp', 'ReadingCelsius', 'RelatedItem',
-                      'SensorNumber']
+                      'SensorNumber', 'Status']
 
         # Go through list
         for chassis_uri in self.chassis_uris:


Test patch:
Repository: ansible-collections/community.general

Issue:
Misleading documentation for maximum_timeout in gitlab_runner
### Summary

The documentation for the `maximum_timeout` parameter of `community.general.gitlab_runner` states:
`The maximum timeout that a runner has to pick up a specific job.`

I think this is a bit misleading as I understand "pick up a specific job" in the sense on how long a job can be in a "pending" state before it is started.
However the parameter is used to configure how long a job can run on that specific runner.

This is indicated by the description provided by gitlab when configuring this value in the Gitlab-UI. 
![image](https://user-images.githubusercontent.com/15264624/139090888-89aac9b9-b558-4815-a79c-ebdc2ec49a1f.png)
and by the gitlab runner [documentation](https://docs.gitlab.com/ee/ci/runners/configure_runners.html) 
`For each runner, you can specify a maximum job timeout. `

I propose changing the documentation to `The maximum time that a runner has to run a specific job.` and will provide a PR.


### Issue Type

Documentation Report

### Component Name

gitlab_runner

### Ansible Version

latest

### Community.general Version

3.8.0/ main branch

### Configuration

NA

### OS / Environment

online documentation

### Additional Information

_No response_

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:

Resolving patch:
diff --git a/plugins/modules/source_control/gitlab/gitlab_runner.py b/plugins/modules/source_control/gitlab/gitlab_runner.py
--- a/plugins/modules/source_control/gitlab/gitlab_runner.py
+++ b/plugins/modules/source_control/gitlab/gitlab_runner.py
@@ -92,7 +92,7 @@
     type: str
   maximum_timeout:
     description:
-      - The maximum timeout that a runner has to pick up a specific job.
+      - The maximum time that a runner has to complete a specific job.
     required: False
     default: 3600
     type: int


Test patch:
Repository: ansible-collections/community.general

Issue:
Misleading documentation for maximum_timeout in gitlab_runner
### Summary

The documentation for the `maximum_timeout` parameter of `community.general.gitlab_runner` states:
`The maximum timeout that a runner has to pick up a specific job.`

I think this is a bit misleading as I understand "pick up a specific job" in the sense on how long a job can be in a "pending" state before it is started.
However the parameter is used to configure how long a job can run on that specific runner.

This is indicated by the description provided by gitlab when configuring this value in the Gitlab-UI. 
![image](https://user-images.githubusercontent.com/15264624/139090888-89aac9b9-b558-4815-a79c-ebdc2ec49a1f.png)
and by the gitlab runner [documentation](https://docs.gitlab.com/ee/ci/runners/configure_runners.html) 
`For each runner, you can specify a maximum job timeout. `

I propose changing the documentation to `The maximum time that a runner has to run a specific job.` and will provide a PR.


### Issue Type

Documentation Report

### Component Name

gitlab_runner

### Ansible Version

latest

### Community.general Version

3.8.0/ main branch

### Configuration

NA

### OS / Environment

online documentation

### Additional Information

_No response_

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:
Files identified in the description:
* [`plugins/modules/source_control/gitlab/gitlab_runner.py`](https://github.com/ansible-collections/community.general/blob/main/plugins/modules/source_control/gitlab/gitlab_runner.py)

If these files are incorrect, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
cc @Lunik @SamyCoenen @Shaps @dj-wasabi @marwatk @metanovii @scodeman @waheedi @zanssa
[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: notify --->

Resolving patch:
diff --git a/plugins/modules/source_control/gitlab/gitlab_runner.py b/plugins/modules/source_control/gitlab/gitlab_runner.py
--- a/plugins/modules/source_control/gitlab/gitlab_runner.py
+++ b/plugins/modules/source_control/gitlab/gitlab_runner.py
@@ -86,7 +86,7 @@
     type: str
   maximum_timeout:
     description:
-      - The maximum timeout that a runner has to pick up a specific job.
+      - The maximum time that a runner has to complete a specific job.
     required: False
     default: 3600
     type: int


Test patch:
Repository: ansible-collections/community.general

Issue:
Misleading documentation for maximum_timeout in gitlab_runner
### Summary

The documentation for the `maximum_timeout` parameter of `community.general.gitlab_runner` states:
`The maximum timeout that a runner has to pick up a specific job.`

I think this is a bit misleading as I understand "pick up a specific job" in the sense on how long a job can be in a "pending" state before it is started.
However the parameter is used to configure how long a job can run on that specific runner.

This is indicated by the description provided by gitlab when configuring this value in the Gitlab-UI. 
![image](https://user-images.githubusercontent.com/15264624/139090888-89aac9b9-b558-4815-a79c-ebdc2ec49a1f.png)
and by the gitlab runner [documentation](https://docs.gitlab.com/ee/ci/runners/configure_runners.html) 
`For each runner, you can specify a maximum job timeout. `

I propose changing the documentation to `The maximum time that a runner has to run a specific job.` and will provide a PR.


### Issue Type

Documentation Report

### Component Name

gitlab_runner

### Ansible Version

latest

### Community.general Version

3.8.0/ main branch

### Configuration

NA

### OS / Environment

online documentation

### Additional Information

_No response_

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:
Files identified in the description:
* [`plugins/modules/source_control/gitlab/gitlab_runner.py`](https://github.com/ansible-collections/community.general/blob/main/plugins/modules/source_control/gitlab/gitlab_runner.py)

If these files are incorrect, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
cc @Lunik @SamyCoenen @Shaps @dj-wasabi @marwatk @metanovii @scodeman @waheedi @zanssa
[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: notify --->

Resolving patch:
diff --git a/plugins/modules/source_control/gitlab/gitlab_runner.py b/plugins/modules/source_control/gitlab/gitlab_runner.py
--- a/plugins/modules/source_control/gitlab/gitlab_runner.py
+++ b/plugins/modules/source_control/gitlab/gitlab_runner.py
@@ -92,7 +92,7 @@
     type: str
   maximum_timeout:
     description:
-      - The maximum timeout that a runner has to pick up a specific job.
+      - The maximum time that a runner has to complete a specific job.
     required: False
     default: 3600
     type: int


Test patch:
Repository: ansible-collections/community.general

Issue:
Allow community.general.ldap_search to be used even in check mode
### Summary

It looks like community.general.ldap_search does no return data if using check mode. You have to use "check_mode=no" to get data if testing. It's a search, so nothing should be changed anyways. So whether or not "--check" is used when calling the playbook the correct result should be returned. 


### Issue Type

Feature Idea

### Component Name

community.general.ldap_search

### Additional Information

<!--- Paste example playbooks or commands between quotes below -->
```yaml (paste below)

```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:
Files identified in the description:
* [`plugins/modules/net_tools/ldap/ldap_search.py`](https://github.com/ansible-collections/community.general/blob/main/plugins/modules/net_tools/ldap/ldap_search.py)

If these files are incorrect, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
cc @eryx12o45 @jtyr
[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: notify --->
The culprit is https://github.com/ansible-collections/community.general/blob/main/plugins/modules/net_tools/ldap/ldap_search.py#L109 which simply skips the module's code if check mode is active.
@sabman3 this seems to be a very simple and straightforward change. If you would be willing to send a pull-request for that, we would be more than happy to assist you on that process.

@russoz I'm working on it. This is my first time contributing to a public GitHub project. I think I got the procedure correct. Also want to verify my change work in both check mode and non-check mode so it's backwards compatible for those that did use check_mode no as a workaroung.

Resolving patch:
diff --git a/plugins/modules/net_tools/ldap/ldap_search.py b/plugins/modules/net_tools/ldap/ldap_search.py
--- a/plugins/modules/net_tools/ldap/ldap_search.py
+++ b/plugins/modules/net_tools/ldap/ldap_search.py
@@ -106,11 +106,10 @@ def main():
         module.fail_json(msg=missing_required_lib('python-ldap'),
                          exception=LDAP_IMP_ERR)
 
-    if not module.check_mode:
-        try:
-            LdapSearch(module).main()
-        except Exception as exception:
-            module.fail_json(msg="Attribute action failed.", details=to_native(exception))
+    try:
+        LdapSearch(module).main()
+    except Exception as exception:
+        module.fail_json(msg="Attribute action failed.", details=to_native(exception))
 
     module.exit_json(changed=False)
 


Test patch:
Repository: ansible-collections/community.general

Issue:
redfish_command: example command has wrong arg
### Summary

The example in `redfish_command` is missing underscore in the arg `boot_next`:
```yaml
- name: Set one-time boot to BiosSetup
  community.general.redfish_command:
    category: Systems
    command: SetOneTimeBoot
    bootnext: BiosSetup
    boot_override_mode: Legacy
    baseuri: "{{ baseuri }}"
    username: "{{ username }}"
    password: "{{ password }}"
```

There is another example command that has the right arg:
```yaml
- name: Set one-time boot device to BootNext target of "Boot0001"
  community.general.redfish_command:
    category: Systems
    command: SetOneTimeBoot
    resource_id: 437XR1138R2
    bootdevice: "UefiBootNext"
    boot_next: "Boot0001"
    baseuri: "{{ baseuri }}"
    username: "{{ username }}"
    password: "{{ password }}"
```

### Issue Type

Bug Report

### Component Name

redfish_command

### Ansible Version

```console (paste below)
$ ansible --version
2.11.6
```


### Community.general Version

```console (paste below)
$ ansible-galaxy collection list community.general
not relevant
```


### Configuration

```console (paste below)
$ ansible-config dump --only-changed
not relevant
```


### OS / Environment

not relevant

### Steps to Reproduce

<!--- Paste example playbooks or commands between quotes below -->
Try to execute the example command would fail with unknown arg `bootnext`.

### Expected Results

The example command should have the right arg.

### Actual Results

```console (paste below)

```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:

Resolving patch:
diff --git a/plugins/modules/remote_management/redfish/redfish_command.py b/plugins/modules/remote_management/redfish/redfish_command.py
--- a/plugins/modules/remote_management/redfish/redfish_command.py
+++ b/plugins/modules/remote_management/redfish/redfish_command.py
@@ -307,7 +307,7 @@
     community.general.redfish_command:
       category: Systems
       command: SetOneTimeBoot
-      bootnext: BiosSetup
+      boot_next: BiosSetup
       boot_override_mode: Legacy
       baseuri: "{{ baseuri }}"
       username: "{{ username }}"


Test patch:
Repository: ansible-collections/community.general

Issue:
redfish_command: example command has wrong arg
### Summary

The example in `redfish_command` is missing underscore in the arg `boot_next`:
```yaml
- name: Set one-time boot to BiosSetup
  community.general.redfish_command:
    category: Systems
    command: SetOneTimeBoot
    bootnext: BiosSetup
    boot_override_mode: Legacy
    baseuri: "{{ baseuri }}"
    username: "{{ username }}"
    password: "{{ password }}"
```

There is another example command that has the right arg:
```yaml
- name: Set one-time boot device to BootNext target of "Boot0001"
  community.general.redfish_command:
    category: Systems
    command: SetOneTimeBoot
    resource_id: 437XR1138R2
    bootdevice: "UefiBootNext"
    boot_next: "Boot0001"
    baseuri: "{{ baseuri }}"
    username: "{{ username }}"
    password: "{{ password }}"
```

### Issue Type

Bug Report

### Component Name

redfish_command

### Ansible Version

```console (paste below)
$ ansible --version
2.11.6
```


### Community.general Version

```console (paste below)
$ ansible-galaxy collection list community.general
not relevant
```


### Configuration

```console (paste below)
$ ansible-config dump --only-changed
not relevant
```


### OS / Environment

not relevant

### Steps to Reproduce

<!--- Paste example playbooks or commands between quotes below -->
Try to execute the example command would fail with unknown arg `bootnext`.

### Expected Results

The example command should have the right arg.

### Actual Results

```console (paste below)

```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct


Discussion:
Files identified in the description:
* [`plugins/modules/remote_management/redfish/redfish_command.py`](https://github.com/ansible-collections/community.general/blob/main/plugins/modules/remote_management/redfish/redfish_command.py)

If these files are incorrect, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
cc @mraineri @renxulei @tomasg2012 @xmadsen
[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: notify --->

Resolving patch:
diff --git a/plugins/modules/remote_management/redfish/redfish_command.py b/plugins/modules/remote_management/redfish/redfish_command.py
--- a/plugins/modules/remote_management/redfish/redfish_command.py
+++ b/plugins/modules/remote_management/redfish/redfish_command.py
@@ -307,7 +307,7 @@
     community.general.redfish_command:
       category: Systems
       command: SetOneTimeBoot
-      bootnext: BiosSetup
+      boot_next: BiosSetup
       boot_override_mode: Legacy
       baseuri: "{{ baseuri }}"
       username: "{{ username }}"


Test patch: