docs(fluxcd): add Limitations section and update controller version

docs/user-guide/creating-application/fluxcd.md

@@ -128,7 +128,7 @@ You can install FluxCD Controller by any of the following ways:
 4. Run the following command to install the FluxCD Controller:
 
       ```yaml
-      kubectl apply -f https://github.com/fluxcd/flux2/releases/download/v0.35.0/install.yaml
+      kubectl apply -f https://github.com/fluxcd/flux2/releases/download/v2.7.5/install.yaml
       ```
 
       ![](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/devtron-v2/resources/gitops-flux-cd/fluxcd-install-controller.gif)
@@ -173,4 +173,22 @@ To install FluxCD controller via Chart Store, follow the below steps.
 
  6. Click **Deploy** and the chart will be deployed.
 
-After the chart is successfully deployed, you can deploy applications though GitOps (via FluxCD).
+After the chart is successfully deployed, you can deploy applications though GitOps (via FluxCD).
+
+## Limitations
+
+Keep the following limitations in mind when using GitOps deployments via FluxCD:
+
+* **Supported deployment strategies**: Only the `Deployment` and `Rollout` strategies are supported (with the latest chart versions). Other strategies (such as Canary or Blue-Green) are currently not supported.
+
+* **No rollback**: Rolling back a FluxCD deployment to a previous version from within Devtron is not currently supported.
+
+* **No manual sync from Devtron**: There is no manual *sync* or *refresh* action for FluxCD applications in Devtron. Deployments reconcile automatically on FluxCD's reconciliation interval. To force an immediate reconcile, use the FluxCD CLI, for example:
+
+      ```bash
+      flux reconcile helmrelease <app-name> -n <namespace>
+      ```
+
+* **Manual controller setup required**: Devtron does not install the FluxCD controller automatically. You must install it in every target cluster (see [Installing FluxCD Controller](#installing-fluxcd-controller-only-for-deployments)) and enable the required feature flags before you can deploy.
+
+* **Prerequisites**: FluxCD deployments require the [Build and Deploy (CI/CD)](../integrations/build-and-deploy-ci-cd.md) and [GitOps (ArgoCD)](../integrations/argocd.md) integrations to be installed.

docs/user-guide/creating-application/workflow/ci-pipeline.md

@@ -817,6 +817,19 @@ You have the option to ignore cache while triggering a build (regardless of the
 If the caching flags in **Global Settings** are set to false, ignoring cache becomes the default behavior even if you don't select the 'Ignore Cache' checkbox during trigger.
 :::
 
+#### Caching for Multi-Architecture Builds
+
+When you build for multiple [target platforms](../../creating-application/docker-build-configuration.md#set-target-platform-for-the-build) (multi-architecture builds), Devtron uses BuildX and, when caching is enabled, maintains a **separate build cache per target architecture** so that each platform's layers are reused across builds.
+
+Super-admins can tune multi-architecture build caching using the following additional flags in the `orchestrator-cm` ConfigMap:
+
+| Flag | Default | Description |
+|:---|:---|:---|
+| `BUILDX_CACHE_MODE_MIN` | `false` | Controls the BuildX cache mode. When `false`, mode `max` is used — all intermediate layers are cached for maximum reuse, at the cost of a larger cache. When `true`, mode `min` is used — only the final exported layers are cached, resulting in a smaller cache. |
+| `ASYNC_BUILDX_CACHE_EXPORT` | `false` | When `true`, the BuildX cache is exported **asynchronously after** the build completes, which can reduce build time. This applies only when using a multi-node BuildX Kubernetes driver. |
+
+After updating these flags, restart the orchestrator deployment for the changes to take effect.
+
 ###  Override Build Configuration
 
 **Override Options** in **Build Stage** lets you override **Build Configurations** for each workflow of the same application. You can configure overrides in the build stage of each workflow.