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

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

@@ -34,10 +34,6 @@ To enable deployments through GitOps via FluxCD, you need to enable a specific f
  |**Deployments via FluxCD**|`FEATURE_FLUX_DEPLOYMENTS_ENABLE: "true"`|This flag will enable deployments through GitOps via FluxCD.<ul><li> After enabling this flag, you also need to install FluxCD controller in order to deploy applications successfully. Refer [Installing FluxCD Controller](#installing-fluxcd-controller-only-for-deployments) to know more.</li></ul>|
  |**Migrating existing FluxCD applications**|`FEATURE_LINK_EXTERNAL_FLUX_ENABLE: "true"`|This flag will enable migrations for external FluxCD apps into Devtron.|
 
- :::caution Deployment Strategies for FluxCD Deployments
- Application deployments through GitOps (via FluxCD) are supported only when using the `Deployment` or `Rollout` deployment strategies with the latest chart versions. Other deployment strategies are currently not supported. 
-:::
-
 ### Enabling Feature Flags
 
 1. Navigate to Devtron's **Resource Browser**.
@@ -128,7 +124,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 +169,32 @@ 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).
+
+## Advanced Configuration (Optional)
+
+The following **orchestrator** environment variables tune the status-polling and timeout cadence for FluxCD apps. They do **not** enable any feature — the defaults are sensible, so change them only if you have a specific need. Note these are set on the **orchestrator**, not in the `dashboard-cm` ConfigMap used for the feature flags above.
+
+| Env variable | Default | Purpose |
+|---|---|---|
+| `CD_FLUX_PIPELINE_STATUS_CRON_TIME` | `*/2 * * * *` | Cron frequency for checking FluxCD CD-pipeline deployment status |
+| `FLUX_CD_PIPELINE_STATUS_CHECK_ELIGIBLE_TIME` | `120` (sec) | Re-check a pipeline's status only if it was not updated within this window |
+| `FLUX_INSTALLATION_STATUS_CRON_TIME` | `1` (min) | Polling interval for tracking FluxCD installation status |
+| `FLUX_INSTALLATION_DELETE_CRON_TIME` | `1` (min) | Polling interval for tracking FluxCD installation delete status |
+| `FLUX_INSTALLATION_HELM_RELEASE_CRON_TIME` | `30` (sec) | Scan interval for HelmReleases stuck in *Applying* (timeout) or *Pending* (missed event) |
+| `FLUX_APPLY_STATUS_TIMEOUT` | `2` (min) | Duration after which a HelmRelease moves from *Applying* to *TimedOut* |
+| `FLUX_PENDING_STATUS_TIME` | `3` (min) | Duration after which an event is emitted for an install stuck in *Pending* |
+
+## Limitations
+
+Keep the following limitations in mind when using GitOps deployments via FluxCD:
+
+* **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.