Merge branch 'main' into discussions-edits

Author: Sharra-writes

.github/workflows/generate-code-scanning-query-lists.yml

@@ -87,7 +87,7 @@ jobs:
 
       - name: Build code scanning query list
         run: |
-          for lang in "actions" "cpp" "csharp" "go" "java" "javascript" "python" "ruby" "swift"; do
+          for lang in "actions" "cpp" "csharp" "go" "java" "javascript" "python" "ruby" "rust" "swift"; do
             echo "Generating code scanning query list for $lang"
             npm run generate-code-scanning-query-list -- \
               --verbose \

.github/workflows/index-autocomplete-search.yml

@@ -1,7 +1,7 @@
 name: Index autocomplete search in Elasticsearch
 
-# **What it does**: Indexes autocomplete data (general and AI search) into Elasticsearch.
-# **Why we have it**: So we can power the APIs for autocomplete.
+# **What it does**: Indexes AI search autocomplete data into Elasticsearch.
+# **Why we have it**: So we can power the APIs for AI search autocomplete.
 # **Who does it impact**: docs-engineering
 
 on:
@@ -40,11 +40,6 @@ jobs:
         if: ${{ github.event_name == 'pull_request' }}
         run: curl --fail --retry-connrefused --retry 5 -I http://localhost:9200
 
-      - name: Run general auto-complete indexing
-        env:
-          ELASTICSEARCH_URL: ${{ github.event_name == 'pull_request' && 'http://localhost:9200' || secrets.ELASTICSEARCH_URL }}
-        run: npm run index-general-autocomplete -- docs-internal-data
-
       - name: Run AI search auto-complete indexing
         env:
           ELASTICSEARCH_URL: ${{ github.event_name == 'pull_request' && 'http://localhost:9200' || secrets.ELASTICSEARCH_URL }}

.github/workflows/test.yml

@@ -75,7 +75,6 @@ jobs:
           - shielding
           # - tests
           # - tools
-          - tracking
           - versions
           - webhooks
           - workflows

.github/workflows/triage-stale-check.yml

@@ -48,6 +48,7 @@ jobs:
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
           stale-pr-message: 'This is a gentle bump for the docs team that this PR is waiting for review.'
+          days-before-issue-stale: -1
           days-before-pr-stale: 14
           days-before-pr-close: -1 # Never close
           remove-stale-when-updated: false

.vscode/settings.json

@@ -39,12 +39,10 @@ While ARC may be deployed successfully with different tooling and configurations
 * Installation tooling other than Helm
 * Service account and/or template spec customization
 
-If you're uncertain if the issue is out of scope, open a ticket and we're happy to help you determine the best way to proceed.
-
 For more information about contacting {% data variables.contact.github_support %}, see [AUTOTITLE](/support/contacting-github-support).
 
 > [!NOTE]
-> * OpenShift clusters are currently unsupported.
+> * OpenShift clusters are in public preview. See guidance from [Red Hat](https://developers.redhat.com/articles/2025/02/17/how-securely-deploy-github-arc-openshift#arc_architecture) for configuration recommendations.
 > * ARC is only supported on GitHub Enterprise Server versions 3.9 and greater.
 
 ## Working with {% data variables.contact.github_support %} for Actions Runner Controller

assets/images/help/copilot/tell-me-about-repo.png

@@ -85,6 +85,108 @@ ARC can use {% data variables.product.pat_v1_plural %} to register self-hosted r
 
    {% data reusables.actions.actions-runner-controller-helm-chart-options %}
 
+## Authenticating ARC with vault secrets
+
+> [!NOTE]
+> Vault integration is currently available in public preview with support for Azure Key Vault.
+
+Starting with gha-runner-scale-set version 0.12.0, ARC supports retrieving GitHub credentials from an external vault. Vault integration is configured per runner scale set. This means you can run some scale sets using Kubernetes secrets while others use vault-based secrets, depending on your security and operational requirements.
+
+### Enabling Vault Integration
+
+To enable vault integration for a runner scale set:
+
+1. **Set the `githubConfigSecret` field** in your `values.yaml` file to the name of the secret key stored in your vault. This value must be a string.
+1. **Uncomment and configure the `keyVault` section** in your `values.yaml` file with the appropriate provider and access details.
+1. **Provide the required certificate** (`.pfx`) to both the controller and the listener. You can do this by:
+   *Rebuilding the controller image with the certificate included, or
+   *Mounting the certificate as a volume in both the controller and the listener using the `listenerTemplate` and `controllerManager` fields.
+
+### Secret Format
+
+The secret stored in Azure Key Vault must be in JSON format. The structure depends on the type of authentication you are using:
+
+#### Example: GitHub Token
+
+```json
+{
+  "github_token": "TOKEN"
+}
+```
+
+#### Example: GitHub App
+
+```json
+{
+  "github_app_id": "APP_ID_OR_CLIENT_ID",
+  "github_app_installation_id": "INSTALLATION_ID",
+  "github_app_private_key": "PRIVATE_KEY"
+}
+```
+
+### Configuring `values.yaml` for Vault Integration
+
+The certificate is stored as a .pfx file and mounted to the container at /akv/cert.pfx. Below is an example of how to configure the keyVault section to use this certificate for authentication:
+
+```yaml
+keyVault:
+  type: "azure_key_vault"
+  proxy:
+    https:
+      url: "PROXY_URL"
+      credentialSecretRef: "PROXY_CREDENTIALS_SECRET_NAME"
+    http: {}
+    noProxy: []
+  azureKeyVault:
+    clientId: <AZURE_CLIENT_ID>
+    tenantId: <AZURE_TENANT_ID>
+    url: <AZURE_VAULT_URL>
+    certificatePath: "/akv/cert.pfx"
+```
+
+### Providing the Certificate to the Controller and Listener
+
+ARC requires a `.pfx` certificate to authenticate with the vault. This certificate must be made available to both the controller and the listener components during controller installation.
+You can do this by mounting the certificate as a volume using the `controllerManager` and `listenerTemplate` fields in your `values.yaml` file:
+
+```yaml
+volumes:
+  - name: cert-volume
+    secret:
+      secretName: my-cert-secret
+volumeMounts:
+  - mountPath: /akv
+    name: cert-volume
+    readOnly: true
+
+listenerTemplate:
+  volumeMounts:
+    - name: cert-volume
+      mountPath: /akv/certs
+      readOnly: true
+  volumes:
+    - name: cert-volume
+      secret:
+        secretName: my-cert-secret
+```
+
+The code below is an example of a scale set `values.yml` file.
+
+```yaml
+listenerTemplate:
+  spec:
+    containers:
+      - name: listener
+        volumeMounts:
+          - name: cert-volume
+            mountPath: /akv
+            readOnly: true
+    volumes:
+      - name: cert-volume
+        secret:
+          secretName: my-cert-secret
+```
+
 ## Legal notice
 
 {% data reusables.actions.actions-runner-controller-legal-notice %}

assets/images/help/copilot/vsc-mcp-server-restart.png

@@ -47,59 +47,52 @@ To use OIDC with JFrog, establish a trust relationship between {% data variables
 
 ## Updating your {% data variables.product.prodname_actions %} workflow
 
-Once you establish a trust relationship between {% data variables.product.prodname_actions %} and the JFrog platform, you can update your {% data variables.product.prodname_actions %} workflow file.
+### Authenticating with JFrog using OIDC
 
 In your {% data variables.product.prodname_actions %} workflow file, ensure you are using the provider name and audience you configured in the JFrog Platform.
 
-The following example uses the placeholder `YOUR_PROVIDER_NAME`.
+The following example uses the placeholders `YOUR_PROVIDER_NAME` and `YOUR_AUDIENCE`.
 
 ```yaml
-- name: Fetch Access Token from Artifactory
-        id: fetch_access_token
-        env:
-          ID_TOKEN: ${{ steps.idtoken.outputs.id_token }}
-        run: |
-          ACCESS_TOKEN=$(curl \
-          -X POST \
-          -H "Content-type: application/json" \
-          https://example.jfrog.io/access/api/v1/oidc/token \
-          -d \
-          "{\"grant_type\": \"urn:ietf:params:oauth:grant-type:token-exchange\", \"subject_token_type\":\"urn:ietf:params:oauth:token-type:id_token\", \"subject_token\": \"$ID_TOKEN\", \"provider_name\": \"YOUR_PROVIDER_NAME\"}" | jq .access_token | tr -d '"')
-          echo ACCESS_TOKEN=$ACCESS_TOKEN >> $GITHUB_OUTPUT
-```
-
-The following example shows part of a {% data variables.product.prodname_actions %} workflow file using cURL.
-
-```yaml
-- name: Get ID Token (cURL method)
-        id: idtoken
-        run: |
-          ID_TOKEN=$(curl -sLS -H "User-Agent: actions/oidc-client" -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
-          "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=jfrog-github" | jq .value | tr -d '"')
-          echo "ID_TOKEN=${ID_TOKEN}" >> $GITHUB_OUTPUT
-```
-
-Alternatively, you can set the audience as an environment variable using the `env` context. For more information about the `env` context, see [AUTOTITLE](/actions/learn-github-actions/contexts#env-context).
-
-{% data reusables.actions.oidc-deployment-protection-rules %}
+permissions:
+  id-token: write
+  contents: read
 
-```yaml
 jobs:
   build:
     runs-on: ubuntu-latest
-    env:
-      OIDC_AUDIENCE: 'YOUR_AUDIENCE'
+    steps:
+      - name: Set up JFrog CLI with OIDC
+        id: setup-jfrog-cli
+        uses: jfrog/setup-jfrog-cli@29fa5190a4123350e81e2a2e8d803b2a27fed15e
+        with:
+          JF_URL: ${{ env.JF_URL }}
+          oidc-provider-name: 'YOUR_PROVIDER_NAME' 
+          oidc-audience: 'YOUR_AUDIENCE' # This is optional
+
+      - name: Upload artifact
+        run: jf rt upload "dist/*.zip" my-repo/
+
 ```
 
-Then, in your workflow file, retrieve the value of the variables stored in the `env` context. The following example uses the `env` context to retrieve the OIDC audience.
+> [!TIP]
+> When OIDC authentication is used, the `setup-jfrog-cli` action automatically provides `oidc-user` and `oidc-token` as step outputs.
+> These can be used for other integrations that require authentication with JFrog.
+> To reference these outputs, ensure the step has an explicit `id` defined (for example `id: setup-jfrog-cli`).
 
+### Using OIDC Credentials in other steps
 ```yaml
-- name: Get ID Token (using env context)
-        uses: {% data reusables.actions.action-github-script %}
-        id: idtoken
+      - name: Sign in to Artifactory Docker registry
+        uses: docker/login-action@v3
         with:
-          script: |
-            const coredemo = require('@actions/core');
-            let id_token = await coredemo.getIDToken(process.env.OIDC_AUDIENCE);
-            coredemo.setOutput('id_token', id_token);
+          registry: ${{ env.JF_URL }}
+          username: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
+          password: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}
+```
+
+## Further reading
+
+- [OpenID Connect Integration](https://jfrog.com/help/r/jfrog-platform-administration-documentation/openid-connect-integration) in the JFrog documentation
+- [Identity Mappings](https://jfrog.com/help/r/jfrog-platform-administration-documentation/identity-mappings) in the JFrog documentation
+- [AUTOTITLE](actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)
 ```