Merge branch 'main' into CDS-108552

Author: SushrutHarness

docs/cloud-cost-management/4-use-ccm-cost-optimization/1-optimize-cloud-costs-with-intelligent-cloud-auto-stopping-rules/2-configure-ecg-for-auto-stopping-rules.md

@@ -144,36 +144,55 @@ Autostopping ECG provides the capability to track the user session and stop the
 
 To install ECG on Windows and track user session, please follow the steps below.
 
-1. Setup an Autostopping rule for the VM. Use this tutorial for reference.
+1. Setup an Autostopping rule for the VM in Harness using the [UI](https://developer.harness.io/docs/category/create-autostopping-rules) or [Terraform](https://registry.terraform.io/providers/harness/harness/latest/docs/resources/autostopping_rule_vm).
 
-2. Login to the VM under Autostopping
+2. Login to the target Windows VM and open a Powershell session as Administrator
 
-3. Download and unzip latest ECG. (Update this link if a new version is released) : https://lightwing-downloads-temp.s3.ap-south-1.amazonaws.com/ecg/harness_autostop_ecg_windows_amd64.zip
+3. Download and unzip the latest ECG release:
 
-4. Open CMD as Administrator
+```
+Invoke-WebRequest -Uri "https://lightwing-downloads-temp.s3.ap-south-1.amazonaws.com/ecg/harness_autostop_ecg_windows_amd64.zip" -OutFile "./Downloads\harness_autostop_ecg_windows_amd64.zip"
+
+Expand-Archive -Path "./Downloads\harness_autostop_ecg_windows_amd64.zip" -DestinationPath "./Downloads\harness_autostop_ecg_windows_amd64"
+cd ecg_1.2.0_linux_amd64
+```
 
-5. Make the binary a windows executable and move it to where it should live perminetly, it is recommended to create a folder for this:
+4. Create a new folder and move the executable into it:
 
 ```
 mkdir C:\Users\Administrator\harness
 mv .\Downloads\harness_autostop_ecg_windows_amd64\harness_autostop_ecg_windows_amd64 C:\Users\Administrator\harness\harness_autostop_ecg_windows_amd64.exe
 ```
 
-6. Run the following commands to set the environment variables at the system level needed for ECG
+5. Configure the ECG by setting global environment variables on the machine:
+
+```
+setx ECG_accountID "{account_id}" /M
+setx ECG_apiURL "https://app.harness.io/gateway/lw/api" /M
+setx ECG_ruleHostName "{host_name}" /M
+setx ECG_user_session_watch "true" /M
+```
+
+Where you should replace `{account_id}` with your Harness account id, and `{host_name}` with the hostname of your autostopping rule (without the `http://`)
 
-- `setx ECG_ruleHostName "{host_name}" /M` - Replace `{host_name}` with Autostopping rule host name
-**Be sure and remove “https://” from the hostname**
-- `setx ECG_accountID "{account_id}" /M `- Replace `"{account_id}"` with Harness Account ID
-- `setx ECG_apiURL "https://app.harness.io/gateway/lw/api" /M`
-- `setx ECG_user_session_watch "true" /M`
+![](./static/configure-ecg-for-auto-stopping-rules-00.png)
+
+If you use a non-standard Harness URL, you can change the `apiURL` accordingly.
+
+6. Finally install the ECG as a Windows service and start it
+
+```
+cd C:\Users\Administrator\harness
+./harness_autostop_ecg_windows_amd64.exe install
+Start-Service Harness-ecg
+```
 
-7. Install ECG using the following command. This will install ECG as a service on Windows.
+## Validation
+
+You can validate the service is running by opening `Services` in Windows and locating the `Harness Autostopping Heartbeat` service.
 
-- Navigate into the folder where you placed the executable: `cd C:\Users\Administrator\harness`
-- Run `./harness_autostop_ecg_windows_amd64.exe install`
-- Verify the running in Windows services. A new service with the name `Harness Autostopping heart beat agent` will be listed under the services with the status Running
-- If it does not start, click `start`.
 ![](./static/windows-ecg-one.png)
 
-![](./static/windows-ecg-two.png)
-- Logout from the current session, verify the VM is stopped after the idle time
+You should also be able to see activity metrics being sent to Harness by looking at the logs on your autostopping rule in the CCM UI.
+
+The service should restart manually on reboot. Such that after a successful shutdown by Harness, when a user restarts the machine and logs in, the machine won't be deemed "idle" until all users have logged off the machine. The machine should shut off after the defined idle period on the rule.

docs/cloud-cost-management/4-use-ccm-cost-optimization/1-optimize-cloud-costs-with-intelligent-cloud-auto-stopping-rules/static/configure-ecg-for-auto-stopping-rules-00.png

@@ -85,6 +85,18 @@ Harness supports the following methods for GCP authentication:
 - **Service Account**:  
    Create a GCP connector by providing a Service Account. For more details, refer to [Create a GCP connector](/docs/platform/connectors/cloud-providers/connect-to-google-cloud-platform-gcp).  
 
+### Enable Cross-Project Access
+
+You can have one connector scoped to multiple GCP projects, eliminating the need to create separate connectors for each project. With this feature, the connector will allow access to multiple GCP projects.
+
+**Prerequisite** : For OIDC-based connectors, the associated service account (SA) must have cross-project access.
+
+- **Project** (required): It can refer to a **different project** than the one configured in the connector, or the **same project**
+- **Region** (required): It refers to the region where the container will be deployed.
+
+<div align="center">
+  <DocImage path={require('./static/oidc-cross-scope.png')} width="50%" height="50%" title="Click to view full size image" />
+</div>
 
 ## Configure the Execution
 

docs/cloud-cost-management/4-use-ccm-cost-optimization/1-optimize-cloud-costs-with-intelligent-cloud-auto-stopping-rules/static/windows-ecg-two.png

@@ -7,22 +7,33 @@ sidebar_position: 22
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-In Harness CI, you can build images without pushing them. For example, you can use your CI pipeline to test a Dockerfile from your codebase to verify that the resulting image is correct before you push it to your Docker repository.
+In Harness CI, you can build container images without pushing them. This is useful to validate your Dockerfile or check if the image builds successfully before pushing it to a registry.
 
-The build dry run configuration depends on your build infrastructure and the step or plugin you use for your build.
+The dry-run behavior **depends on the image build tool** used by your pipeline step — either **Kaniko** or **Buildx** — **not** on the infrastructure (Kubernetes, Harness Cloud, etc.).
 
-## Harness Cloud, local runner, or self-managed VM
+## Build tool behavior
 
-Use these instructions for build dry runs on Harness Cloud, self-managed VM, or local runner build infrastructure.
+| Build Tool | Dry Run Flag           | Notes                                                                 |
+|------------|------------------------|-----------------------------------------------------------------------|
+| Kaniko     | `PLUGIN_PUSH_ONLY=true`  | Default on Kubernetes unless overridden by feature flag              |
+| Buildx     | `PLUGIN_DRY_RUN=true`  | Used when DLC checkbox is enabled or feature flag switches to Buildx |
+
+**DLC checkbox**: Enabling this forces usage of Buildx regardless of infrastructure.
+
+**Kubernetes users**: You get Kaniko by default. If the Buildx feature flag is enabled, it switches to Buildx — even if the DLC checkbox is off.
+
+## Harness Cloud, Local Runner, or Self-managed VM
+
+These environments use Buildx by default. Add `PLUGIN_DRY_RUN=true` to trigger a dry run.
 
 <Tabs>
 <TabItem value="builtin" label="Built-in Build and Push steps" default>
 
-For built-in [Build and Push steps](/docs/category/build-and-push), you need to add a [**STAGE** variable](/docs/platform/pipelines/add-a-stage/#stage-variables) named `PLUGIN_DRY_RUN`.
+For built-in [Build and Push steps](/docs/category/build-and-push), add a [**STAGE** variable](/docs/platform/pipelines/add-a-stage/#stage-variables):
 
-1. In your CI pipeline, go to the **Build** stage that includes a [Build and Push step](/docs/category/build-and-push).
-2. In the **Build** stage's **Overview** tab, expand the **Advanced** section.
-3. Select **Add Variable** and enter the following:
+1. Go to the **Build** stage with the [Build and Push step](/docs/category/build-and-push).
+2. In the **Overview** tab, expand the **Advanced** section.
+3. Add a variable:
    * **Name:** `PLUGIN_DRY_RUN`
    * **Type:** **String**
    * **Value:** `true`
@@ -31,45 +42,47 @@ For built-in [Build and Push steps](/docs/category/build-and-push), you need to
 </TabItem>
 <TabItem value="run" label="Run step">
 
-For build scripts executed in [Run steps](/docs/continuous-integration/use-ci/run-step-settings), refer to your build tool's documentation for dry run specifications.
+If you're using a [Run step](/docs/continuous-integration/use-ci/run-step-settings) with a custom script, follow the dry-run guidance from your specific build tool (e.g., `docker build`, `buildx build`, etc).
 
 </TabItem>
 </Tabs>
 
-## Kubernetes cluster build infrastructure
-
-Use these instructions for build dry runs on Kubernetes cluster build infrastructure.
+## Kubernetes Cluster Build Infrastructure
 
 <Tabs>
 <TabItem value="builtin" label="Built-in Build and Push steps" default>
 
-For the built-in [Build and Push steps](/docs/category/build-and-push), add the `PLUGIN_NO_PUSH` variable to the **Build and Push** step's **Environment Variables**.
+Kubernetes infra **uses Kaniko by default**. In this case, use the `PLUGIN_PUSH_ONLY` flag:
 
 ```yaml
-                    envVariables:
-                      PLUGIN_NO_PUSH: true
+envVariables:
+  PLUGIN_PUSH_ONLY: true
+```
+
+If your org has enabled the Buildx feature flag (or if DLC is enabled), use:
+
+```yaml
+envVariables:
+  PLUGIN_DRY_RUN: true
 ```
 
 </TabItem>
 <TabItem value="buildah" label="Buildah plugin (Plugin step)">
 
-The Buildah plugin is used to [build and push with non-root users](/docs/continuous-integration/use-ci/build-and-upload-artifacts/build-and-push-nonroot.md).
-
-To configure a build dry run with this plugin, add the following [stage variable](/docs/platform/pipelines/add-a-stage/#stage-variables) to the stage where you run the Buildah plugin:
+For the Buildah plugin (used for non-root image builds), use:
 
 ```yaml
-        variables:
-          - name: PLUGIN_DRY_RUN
-            type: String
-            description: ""
-            required: false
-            value: "true"
+variables:
+  - name: PLUGIN_DRY_RUN
+    type: String
+    value: "true"
 ```
 
 </TabItem>
 <TabItem value="run" label="Run step">
 
-For build scripts executed in [Run steps](/docs/continuous-integration/use-ci/run-step-settings), refer to your build tool's documentation for dry run specifications.
+If you're using a custom build command in a [Run step](/docs/continuous-integration/use-ci/run-step-settings), refer to your tool's own dry-run mechanism.
 
 </TabItem>
 </Tabs>
+```