Ansible Configuration Management user documentation

docs/concepts/configuration-management.md

@@ -0,0 +1,58 @@
+# Configuration Management View
+
+We’re excited to introduce the **Configuration Management View**, a new feature designed to enhance visibility, control, and monitoring of Ansible tasks across your stacks and runs.
+
+This feature replaces or supplements the existing **Resources View** for Ansible stacks, offering a more focused way to monitor the last status of each item in your Ansible inventory. Below is an overview of the updates and functionality:
+
+## Where You’ll Find It
+
+### Stack View
+
+The Configuration Management View is available in the Stack View, replacing the Resources View for Ansible stacks.
+
+![](../assets/screenshots/concepts/configuration-management/stack-view.png)
+
+!!! Info
+    Since the new changes replace _Resources View_ you will not be able to see _Resources View_ in Ansible stacks by default. If you'd like to see it (e.g. because you have some historical resources you want to investigate there), you can toggle between the _Configuration Management View_ and the previous _Resources View_ using the “Enable configuration management view” toggle.
+
+### Resources View
+
+The Configuration Management View is also added as a separate tab in the Resources View.
+
+![](../assets/screenshots/concepts/configuration-management/configuration-management-view.png)
+
+### Run View
+
+The Tasks Tab in the Run View provides detailed visibility into Ansible task execution during a run.
+![](../assets/screenshots/concepts/configuration-management/run-view.png)
+
+## Key Features
+
+### Task Monitoring
+
+- View the last status of every item in your Ansible inventory, showing the outcome of the most recent run.
+- Navigate seamlessly through tasks to analyze their status, logs, and execution details.
+
+### Enhanced Run List View
+
+- The updated run list now includes Ansible statuses, providing immediate insights without diving into individual runs.
+
+### Detailed Logs in Task Details
+
+Access detailed logs for task execution in the task details tab to diagnose and debug issues efficiently.
+
+## Flexibility and Control
+
+Our integration relies on events generated by Ansible, which can vary based on the playbooks, roles, and plugins used. If you encounter issues with the new Configuration Management View, you can revert to the previous logic by enabling the old flow:
+
+### How to Enable the Old Flow
+
+Add the label: `feature:use_ansible_v1_flow` to your Ansible stack.
+This will restore the _Resources View_ to display Ansible tasks instead of using the new _Configuration Management View_.
+
+## Why Use the Configuration Management View?
+
+- Increase Visibility: Unified workflows for all tools, including Terraform, OpenTofu, and Ansible.
+- Encourage Automation: Seamlessly integrate infrastructure control and configuration management with stack dependencies.
+- Improve Audit Capabilities: Collect, analyze, and filter data from execution logs.
+- Understand Tasks Intuitively: Visualize and filter tasks with ease.

docs/concepts/run/tracked.md

@@ -28,6 +28,19 @@ Runs triggered by individuals and [machine users](../../integrations/api.md#spac
 
 ![](../../assets/screenshots/run/run-started-by-real-and-machine-user.png)
 
+#### Triggering runs with a custom runtime config
+
+It is possible to trigger runs with a custom runtime configuration. This allows you to tailor the runtime environment to specific needs at the moment of triggering a run.
+
+![](../../assets/screenshots/run/trigger-with-custom-runtime-config.png)
+
+The details of runtime config format can be found in the section about [runtime YAML reference](../../concepts/configuration/runtime-configuration/runtime-yaml-reference.md)
+
+![](../../assets/screenshots/run/trigger-custom-runtime-config-details.png)
+
+!!! info
+    Triggering runs with custom runtime config is especially useful when last-mile configuration is needed, for example oftentimes when triggering Ansible runs with custom variables and parameters.
+
 ### Triggering from Git events
 
 Tracked runs can also be triggered by Git push and tag events. By default, whenever a push occurs to the [tracked branch](../stack/stack-settings.md#vcs-integration-and-repository), a tracked run is started - one for each of the affected stacks. This default behavior can be extensively customized using our [push policies](../policy/push-policy/README.md).

docs/concepts/stack/scheduling.md

@@ -34,3 +34,11 @@ Add a schedule with the Task type from the Scheduling section of your stack.
 After creating this schedule, a task will be triggered with the defined command (at a specific timestamp or periodically based on the cron rules defined).
 
 ![](../../assets/screenshots/stack/scheduling/create-task.png)
+
+## Scheduled Run
+
+You can also set up a schedule based on which a tracked run will be created.
+
+![](../../assets/screenshots/stack/scheduling/create-run.png)
+
+Additionally, if you mark **Attach custom runtime config**, you will be able to attach a custom runtime config to the schedule, similarly to when [triggering a run with custom runtime config](../run/tracked.md#triggering-runs-with-a-custom-runtime-config).