collection: Update min Ansible version and update workflows

.github/workflows/ansible-lint-sap_control.yml

@@ -24,10 +24,10 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-        # Use @v25 to automatically track the latest release from the year 2025.
-        # ansible-lint uses Calendar Versioning (e.g., v25.9.0 -> YYYY.MM.PATCH).
+        # Use @vXX to automatically track the latest release from the year 20XX. Example: @v26 for 2026.
+        # ansible-lint uses Calendar Versioning (e.g., v26.0.0 -> YYYY.MM.PATCH).
         # Avoid using @main, which can introduce breaking changes unexpectedly.
-      - uses: ansible/ansible-lint@v25
+      - uses: ansible/ansible-lint@v26
         with:
           # v25.7.0 no longer uses 'working_directory' and role path is set in 'args'.
           # Role specific .ansible-lint can be added with argument '-c'.

.github/workflows/ansible-lint-sap_firewall.yml

@@ -24,10 +24,10 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-        # Use @v25 to automatically track the latest release from the year 2025.
-        # ansible-lint uses Calendar Versioning (e.g., v25.9.0 -> YYYY.MM.PATCH).
+        # Use @vXX to automatically track the latest release from the year 20XX. Example: @v26 for 2026.
+        # ansible-lint uses Calendar Versioning (e.g., v26.0.0 -> YYYY.MM.PATCH).
         # Avoid using @main, which can introduce breaking changes unexpectedly.
-      - uses: ansible/ansible-lint@v25
+      - uses: ansible/ansible-lint@v26
         with:
           # v25.7.0 no longer uses 'working_directory' and role path is set in 'args'.
           # Role specific .ansible-lint can be added with argument '-c'.

.github/workflows/ansible-lint-sap_hana_backint.yml

@@ -24,10 +24,10 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-        # Use @v25 to automatically track the latest release from the year 2025.
-        # ansible-lint uses Calendar Versioning (e.g., v25.9.0 -> YYYY.MM.PATCH).
+        # Use @vXX to automatically track the latest release from the year 20XX. Example: @v26 for 2026.
+        # ansible-lint uses Calendar Versioning (e.g., v26.0.0 -> YYYY.MM.PATCH).
         # Avoid using @main, which can introduce breaking changes unexpectedly.
-      - uses: ansible/ansible-lint@v25
+      - uses: ansible/ansible-lint@v26
         with:
           # v25.7.0 no longer uses 'working_directory' and role path is set in 'args'.
           # Role specific .ansible-lint can be added with argument '-c'.

.github/workflows/ansible-lint-sap_hana_sr_takeover.yml

@@ -24,10 +24,10 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-        # Use @v25 to automatically track the latest release from the year 2025.
-        # ansible-lint uses Calendar Versioning (e.g., v25.9.0 -> YYYY.MM.PATCH).
+        # Use @vXX to automatically track the latest release from the year 20XX. Example: @v26 for 2026.
+        # ansible-lint uses Calendar Versioning (e.g., v26.0.0 -> YYYY.MM.PATCH).
         # Avoid using @main, which can introduce breaking changes unexpectedly.
-      - uses: ansible/ansible-lint@v25
+      - uses: ansible/ansible-lint@v26
         with:
           # v25.7.0 no longer uses 'working_directory' and role path is set in 'args'.
           # Role specific .ansible-lint can be added with argument '-c'.

.github/workflows/ansible-lint-sap_profile_update.yml

@@ -24,10 +24,10 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-        # Use @v25 to automatically track the latest release from the year 2025.
-        # ansible-lint uses Calendar Versioning (e.g., v25.9.0 -> YYYY.MM.PATCH).
+        # Use @vXX to automatically track the latest release from the year 20XX. Example: @v26 for 2026.
+        # ansible-lint uses Calendar Versioning (e.g., v26.0.0 -> YYYY.MM.PATCH).
         # Avoid using @main, which can introduce breaking changes unexpectedly.
-      - uses: ansible/ansible-lint@v25
+      - uses: ansible/ansible-lint@v26
         with:
           # v25.7.0 no longer uses 'working_directory' and role path is set in 'args'.
           # Role specific .ansible-lint can be added with argument '-c'.

.github/workflows/ansible-lint.yml

@@ -3,8 +3,8 @@ name: Ansible Lint - Collection
 
 on:
   schedule:
-    # This is 03:05 UTC, which is 5:05 AM in Prague/CEST.
-    - cron: '5 3 * * 1'
+    # Wednesday at 03:17 UTC (~4:17 AM CET / 5:17 AM CEST). Actual start time depends on GitHub load.
+    - cron: '17 3 * * 3'
 
   workflow_dispatch:
 
@@ -15,10 +15,10 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-        # Use @v25 to automatically track the latest release from the year 2025.
-        # ansible-lint uses Calendar Versioning (e.g., v25.9.0 -> YYYY.MM.PATCH).
+        # Use @vXX to automatically track the latest release from the year 20XX. Example: @v26 for 2026.
+        # ansible-lint uses Calendar Versioning (e.g., v26.0.0 -> YYYY.MM.PATCH).
         # Avoid using @main, which can introduce breaking changes unexpectedly.
-      - uses: ansible/ansible-lint@v25
+      - uses: ansible/ansible-lint@v26
         with:
           # Use the shared requirements file from the collection root for dependency context.
           requirements_file: ./requirements.yml

.github/workflows/ansible-test-sanity.yml

@@ -6,13 +6,22 @@ name: Ansible Test - Sanity
 
 on:
   schedule:
-    # This is 01:05 UTC, which is 3:05 AM in Prague/CEST
-    - cron: '5 3 * * 1'
+    # Wednesday at 02:17 UTC (~3:17 AM CET / 4:17 AM CEST). Actual start time depends on GitHub load.
+    - cron: '17 2 * * 3'
 
   pull_request:
     branches:
       - main
       - dev
+    paths-ignore:
+      # Do not trigger workflow for files that do not affect functionality or tests.
+      # This helps reduce unnecessary CI runs and saves resources.
+      - '**.md'             # All markdown files anywhere in the repository.
+      - '**.rst'            # All changelog files anywhere in the repository.
+      - 'docs/**'           # All files inside the docs folder on root level.
+      - 'roles/**/docs/**'  # All files inside the docs folder inside the roles.
+      - 'changelogs/**'     # All files inside the changelogs folder on root level.
+      - 'galaxy.yml'        # Collection metadata file.
 
   workflow_dispatch:
 
@@ -22,13 +31,19 @@ jobs:
     name: Sanity (Supported Ⓐ${{ matrix.ansible }})
     strategy:
       fail-fast: false  # Disabled so we can see all failed combinations.
+
+      # Serialization: Limit number of parallel jobs.
+      # This helps with throughput issues on GitHub Gateway servers.
+      max-parallel: 5
+
       # Define a build matrix to test compatibility across multiple Ansible versions.
       # Each version listed below will spawn a separate job that runs in parallel.
       matrix:
         ansible:
-          # Supported versions (must pass)
           - 'stable-2.18'  # Python 3.11 - 3.13
           - 'stable-2.19'  # Python 3.11 - 3.13
+          - 'stable-2.20'  # Python 3.12 - 3.14
+          - 'stable-2.21'  # Python 3.12 - 3.14
           - 'devel'  # Test against the upcoming development version.
     steps:
       - uses: actions/checkout@v5
@@ -39,46 +54,51 @@ jobs:
           ansible-core-version: ${{ matrix.ansible }}
           testing-type: sanity
 
-  sanity-eol:
-    runs-on: ubuntu-latest
-    # This job only runs if the supported tests pass
-    needs: sanity-supported
-    name: Sanity (EOL Ⓐ${{ matrix.ansible }}+py${{ matrix.python }})
-    continue-on-error: true  # This entire job is allowed to fail
-    strategy:
-      fail-fast: false  # Disabled so we can see all failed combinations.
-      # Define a build matrix to test compatibility across multiple Ansible versions.
-      # Each version listed below will spawn a separate job that runs in parallel.
-      matrix:
-        ansible:
-          - 'stable-2.14'  # Python 3.9 - 3.11
-          - 'stable-2.15'  # Python 3.9 - 3.11
-          - 'stable-2.16'  # Python 3.10 - 3.12
-          - 'stable-2.17'  # Python 3.10 - 3.12
-        python:
-          - '3.9'
-          - '3.10'
-          - '3.11'
-          - '3.12'
-        exclude:
-          # Exclusions for incompatible Python versions.
-          - ansible: 'stable-2.14'
-            python: '3.12'
 
-          - ansible: 'stable-2.15'
-            python: '3.12'
+  # NOTE: Minimum supported Ansible version was changed to 2.18 and these tests no longer work.
+  # It can be uncommented and repurposed when we have a new EOL version of Ansible to test against
+  # while ensuring that it aligns with minimum version defined in meta/runtime.yml.
 
-          - ansible: 'stable-2.16'
-            python: '3.9'
+  # sanity-eol:
+  #   runs-on: ubuntu-latest
+  #   # This job only runs if the supported tests pass
+  #   needs: sanity-supported
+  #   name: Sanity (EOL Ⓐ${{ matrix.ansible }}+py${{ matrix.python }})
+  #   continue-on-error: true  # This entire job is allowed to fail
+  #   strategy:
+  #     fail-fast: false  # Disabled so we can see all failed combinations.
+  #     # Define a build matrix to test compatibility across multiple Ansible versions.
+  #     # Each version listed below will spawn a separate job that runs in parallel.
+  #     matrix:
+  #       ansible:
+  #         - 'stable-2.14'  # Python 3.9 - 3.11
+  #         - 'stable-2.15'  # Python 3.9 - 3.11
+  #         - 'stable-2.16'  # Python 3.10 - 3.12
+  #         - 'stable-2.17'  # Python 3.10 - 3.12
+  #       python:
+  #         - '3.9'
+  #         - '3.10'
+  #         - '3.11'
+  #         - '3.12'
+  #       exclude:
+  #         # Exclusions for incompatible Python versions.
+  #         - ansible: 'stable-2.14'
+  #           python: '3.12'
 
-          - ansible: 'stable-2.17'
-            python: '3.9'
-    steps:
-      - uses: actions/checkout@v5
+  #         - ansible: 'stable-2.15'
+  #           python: '3.12'
 
-      - name: ansible-test - sanity
-        uses: ansible-community/ansible-test-gh-action@release/v1
-        with:
-          ansible-core-version: ${{ matrix.ansible }}
-          target-python-version: ${{ matrix.python }}
-          testing-type: sanity
+  #         - ansible: 'stable-2.16'
+  #           python: '3.9'
+
+  #         - ansible: 'stable-2.17'
+  #           python: '3.9'
+  #   steps:
+  #     - uses: actions/checkout@v5
+
+  #     - name: ansible-test - sanity
+  #       uses: ansible-community/ansible-test-gh-action@release/v1
+  #       with:
+  #         ansible-core-version: ${{ matrix.ansible }}
+  #         target-python-version: ${{ matrix.python }}
+  #         testing-type: sanity

README.md

@@ -15,19 +15,21 @@ This Ansible Collection executes various SAP Systems operational tasks, includin
 ## Requirements
 
 | Component | Control Node | Managed Node |
-| --- | --- | --- |
-| Operating System | Any OS | Red Hat Enterprise Linux for SAP Solutions 8.x, 9.x and 10.x<br>SUSE Linux Enterprise Server for SAP applications 15 SP5, 15 SP6, 15 SP7 and 16.0 |
+| :--- | :--- | :--- |
+| Operating System | Any OS | [See compatible OS versions](#compatible-operating-system-versions) |
 | Python | 3.11 or higher | 3.9 or higher |
 | Ansible-Core | 2.18 or higher | N/A |
-| Ansible | 12 or higher | N/A |
-
-> **Managed Node Registration**<br>
-> Operating system needs to have access to required package repositories either directly or via subscription registration.
 
 **Additional notes:**
 
-- **Version Compatibility:** For a detailed mapping of supported Python versions and Ansible-Core life cycles, refer to the official [Ansible-Core Support Matrix](https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix).
+- **Version Compatibility:** For a detailed mapping of supported Python versions and Ansible-Core lifecycle, refer to the official [Ansible-Core Support Matrix](https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix).
 - **Control Node Permissions:** Ensure the user executing the playbooks has the necessary SSH keys and sudo privileges configured for the target environment.
+- **Managed Node Registration:** Operating system needs to have access to required package repositories either directly or via subscription registration.
+
+### Compatible Operating System Versions
+
+- Red Hat Enterprise Linux for SAP Solutions: 8.x, 9.x, 10.x
+- SUSE Linux Enterprise Server for SAP applications: 15 SP5, 15 SP6, 15 SP7, 16
 
 ## Installation Instructions
 
@@ -79,18 +81,12 @@ See [Installing collections](https://docs.ansible.com/ansible/latest/collections
 > **NOTE: All included modules were deprecated in 2.0.0 release.**<br>
 
 ## Testing
-This Ansible Collection was tested across different Operating Systems, SAP products and scenarios. You can find examples of some of them below.
+This Ansible Collection has been tested across different operating systems, SAP products, and scenarios.
 
 Operating systems:
 
-- Red Hat Enterprise Linux for SAP Solutions 8.x, 9.x and 10.x
-- SUSE Linux Enterprise Server for SAP applications 15 SP7 and 16.0
-
-SAP Products:
-
-- SAP S/4HANA AnyPremise 2023
-- SAP BW/4HANA 2023
-- SAP HANA 2.0 SPS08
+- Red Hat Enterprise Linux for SAP Solutions: 8.x, 9.x, 10.x
+- SUSE Linux Enterprise Server for SAP applications: 15 SP5, 15 SP6, 15 SP7, 16
 
 ## Contributing
 For information on how to contribute, please see our [contribution guidelines](https://sap-linuxlab.github.io/initiative_contributions/).

meta/runtime.yml

@@ -1,2 +1,2 @@
 ---
-requires_ansible: '>=2.16.0'
+requires_ansible: '>=2.18.0'