Merge branch 'main' into ngf-release-2.0

Author: ADubhlaoich

.github/workflows/build-push.yml

@@ -1,5 +1,7 @@
 name: Build and deploy (docs)
 on:
+  repository_dispatch:
+    types: [trigger-preview-build]
   workflow_call:
     inputs:
       environment:
@@ -31,22 +33,22 @@ on:
         type: string
   pull_request:
     branches:
-      - "*"
+      - "**"
   push:
     branches:
       - "main"
 
 env:
   FRONT_DOOR_USERNAME: ${{ secrets.FRONT_DOOR_USERNAME }}
   FRONT_DOOR_PASSWORD: ${{ secrets.FRONT_DOOR_PASSWORD }}
-  GITHUB_PR_NUMBER: ${{ github.event.pull_request.number }}     
+  GITHUB_PR_NUMBER: ${{ github.event.pull_request.number }}    
 jobs:
   prod-check-branch:
     runs-on: ubuntu-24.04
     steps:
       - name: Output variables
         run: |
-          echo "Environment: ${{ inputs.environment }}"
+          echo "Environment: ${{ inputs.environment || github.event.client_payload.environment }}"
           echo "Branch: ${{ github.ref }}"
       - name: Checks to see that main branch is selected if deploying to prod
         if: ${{ inputs.environment == 'prod' && github.ref != 'refs/heads/main' }}
@@ -63,14 +65,33 @@ jobs:
       docs_source_path: "public"
       docs_build_path: "./"
       doc_type: "hugo"
-      environment: ${{inputs.environment}}
+      environment: ${{ inputs.environment || github.event.client_payload.environment }}
       force_hugo_theme_version: ${{inputs.hugo_theme_override}}
       auto_deploy_branch: "main"
       auto_deploy_env: "prod"
     secrets:
       AZURE_CREDENTIALS: ${{secrets.AZURE_CREDENTIALS_DOCS}}
       AZURE_KEY_VAULT: ${{secrets.AZURE_KEY_VAULT_DOCS}}
 
+  trigger-theme-slack-notification:
+    if: github.event_name == 'repository_dispatch'
+    needs: call-docs-build-push
+    runs-on: ubuntu-latest
+    permissions: read-all
+    steps:
+      - name: Trigger 'Slack notification for new theme release' workflow in 'nginx-hugo-theme' repo.
+        run: |
+           curl -L \
+              -X POST \
+              -H "Accept: application/vnd.github+json" \
+              -H "Authorization: Bearer ${{ secrets.THEME_SLACK_FLOW_PAT }}" \
+              -H "X-GitHub-Api-Version: 2022-11-28" \
+              "https://api.github.com/repos/${{ secrets.OWNER }}/${{ secrets.REPO }}/dispatches" \
+              -d "{\"event_type\": \"trigger-slack-notification\", \"client_payload\": {\"previewURL\": \"${{ env.PREVIEW_URL }}\",  \"author\": \"${{ github.event.client_payload.author}}\", \"tag_name\": \"${{ github.event.client_payload.tag_name }}\", \"release_name\": \"${{ github.event.client_payload.release_name }}\"}}"
+    env:
+      PREVIEW_URL: ${{ needs.call-docs-build-push.outputs.PREVIEW_URL }}
+
+
   lighthouseci:
     if: github.event.pull_request
     needs: call-docs-build-push

.github/workflows/ossf_scorecard.yml

@@ -56,6 +56,6 @@ jobs:
 
       # Upload the results to GitHub's code scanning dashboard.
       - name: Upload SARIF results to code scanning
-        uses: github/codeql-action/upload-sarif@45775bd8235c68ba998cffa5171334d58593da47 # v3.28.15
+        uses: github/codeql-action/upload-sarif@28deaeda66b76a05916b6923827895f2b14ab387 # v3.28.16
         with:
           sarif_file: results.sarif

CLOSED_CONTRIBUTIONS.md

@@ -33,7 +33,7 @@ To create closed content, add the closed repository as a remote to the main repo
 ```shell
 cd documentation
 git remote add internal [email protected]:<closed-url>.git
-git fetch
+git fetch --all
 ```
 
 Check out the remote `main` branch, and use it to create a feature branch. **Ensure that you prefix all branch names with `internal/`**
@@ -64,4 +64,4 @@ git merge internal/internal/feature
 git push origin
 ```
 
-Once the content changes have been merged in the open repository, they will synchronize back to the closed repository.
+Once the content changes have been merged in the open repository, they will synchronize back to the closed repository.

content/agent/configuration/configuration-overview.md

@@ -51,11 +51,11 @@ server:
   host: <FQDN>
   grpcPort: 443
   backoff: # note: default values are prepopulated 
-    initial_interval: 100ms # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
-    randomization_factor: 0.10 # Add the appropriate float value here, e.g., 0.10
-    multiplier: 1.5 # Add the appropriate float value here, e.g., 1.5
-    max_interval: 1m # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
-    max_elapsed_time: 0 # Add the appropriate duration value here, e.g., "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
+    initial_interval: 100ms # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
+    randomization_factor: 0.10 # Add the appropriate float value here, for example, 0.10
+    multiplier: 1.5 # Add the appropriate float value here, for example, 1.5
+    max_interval: 1m # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
+    max_elapsed_time: 0 # Add the appropriate duration value here, for example, "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
 # tls options
 tls:
   # enable tls in the nginx-agent setup for grpcs
@@ -89,11 +89,11 @@ metrics:
   collection_interval: 15s
   mode: aggregated
     backoff: # note: default values are prepopulated 
-      initial_interval: 100ms # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
-      randomization_factor: 0.10 # Add the appropriate float value here, e.g., 0.10
-      multiplier: 1.5 # Add the appropriate float value here, e.g., 1.5
-      max_interval: 1m # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
-      max_elapsed_time: 0 # Add the appropriate duration value here, e.g., "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
+      initial_interval: 100ms # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
+      randomization_factor: 0.10 # Add the appropriate float value here, for example, 0.10
+      multiplier: 1.5 # Add the appropriate float value here, for example, 1.5
+      max_interval: 1m # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
+      max_elapsed_time: 0 # Add the appropriate duration value here, for example, "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour
 
 # OSS NGINX default config path
 # path to aux file dirs can also be added
@@ -193,7 +193,7 @@ If you are upgrading from an older version, update your configuration accordingl
 | `--features`                                | `NGINX_AGENT_FEATURES`                       | Specifies a comma-separated list of features enabled for the agent. Default: *[registration, nginx-config-async, nginx-ssl-config, nginx-counting, metrics, dataplane-status, process-watcher, file-watcher, activity-events, agent-api]* |
 | `--ignore-directives`                       |                                      | Specifies a comma-separated list of directives to ignore for sensitive info.|
 | `--instance-group`                          | `NGINX_AGENT_INSTANCE_GROUP`                 | Sets the instance's group value.                                            |
-| `--log-level`                               | `NGINX_AGENT_LOG_LEVEL`                      | Sets the logging level (e.g., panic, fatal, error, info, debug, trace). Default: *info* |
+| `--log-level`                               | `NGINX_AGENT_LOG_LEVEL`                      | Sets the logging level (for example, panic, fatal, error, info, debug, trace). Default: *info* |
 | `--log-path`                                | `NGINX_AGENT_LOG_PATH`                       | Specifies the path to output log messages.                                  |
 | `--metrics-bulk-size`                       | `NGINX_AGENT_METRICS_BULK_SIZE`              | Specifies the number of metrics reports collected before sending data. Default: *20* |
 | `--metrics-collection-interval`             | `NGINX_AGENT_METRICS_COLLECTION_INTERVAL`    | Sets the interval for metrics collection. Default: *15s*                    |

content/amplify/faq/nginx-amplify-agent.md

@@ -82,7 +82,7 @@ If you don't see the new system or NGINX in the web interface, or (some) metrics
 
 3. NGINX Amplify Agent is running under the same user as your NGINX worker processes.
 
-4. The NGINX instance is started with an absolute path. Currently, NGINX Amplify Agent **can't** detect NGINX instances launched with a relative path (e.g., "./nginx").
+4. The NGINX instance is started with an absolute path. Currently, NGINX Amplify Agent **can't** detect NGINX instances launched with a relative path (for example, "./nginx").
 
 5. The [user ID that is used by NGINX Amplify Agent and NGINX ]({{< ref "/amplify/nginx-amplify-agent/install/configuring-amplify-agent#overriding-the-effective-user-id" >}}), can run *ps(1)* to see all system processes. If *ps(1)* is restricted for non-privileged users, NGINX Amplify Agent won't be able to find and properly detect the NGINX master process.
 

content/amplify/nginx-amplify-agent/configuration-analysis.md

@@ -8,7 +8,7 @@ docs: DOCS-961
 
 F5 NGINX Amplify Agent can automatically find all relevant NGINX configuration files, parse them, extract their logical structure, and send the associated JSON data to the Amplify backend for further analysis and reporting. For more information on configuration analysis, please see the [Analyzer]({{< ref "/amplify/user-interface/analyzer.md" >}})) documentation.
 
-After NGINX Amplify Agent finds a particular NGINX configuration, it then automatically starts to keep track of its changes. When a change is detected with NGINX — e.g., a master process restarts, or the NGINX config is edited, an update is sent to the Amplify backend.
+After NGINX Amplify Agent finds a particular NGINX configuration, it then automatically starts to keep track of its changes. When a change is detected with NGINX — for example, a master process restarts, or the NGINX config is edited, an update is sent to the Amplify backend.
 
 {{< note >}} NGINX Amplify Agent never sends the raw unprocessed config files to the backend system. In addition, the following directives in the NGINX configuration are never analyzed — and their parameters aren't exported to the SaaS backend:
 [ssl_certificate_key](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html#ssl_certificate_key), [ssl_client_certificate](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html#ssl_client_certificate), [ssl_password_file](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html#ssl_password_file), [ssl_stapling_file](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling_file), [ssl_trusted_certificate](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate), [auth_basic_user_file](http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file), [secure_link_secret](http://nginx.org/en/docs/http/ngx_http_secure_link_module.html#secure_link_secret).{{< /note >}}

content/amplify/nginx-amplify-agent/configuring-metric-collection.md

@@ -93,7 +93,7 @@ NGINX Amplify Agent will also collect more NGINX metrics from the [access.log](h
 
 You don't have to specifically point NGINX Amplify Agent to either the NGINX configuration or the NGINX log files — it should detect their location automatically.
 
-NGINX Amplify Agent will also try to detect the [log format](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) for a particular log to parse it properly and try to extract even more useful metrics, e.g., [$upstream_response_time](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_response_time).
+NGINX Amplify Agent will also try to detect the [log format](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) for a particular log to parse it properly and try to extract even more useful metrics, for example, [$upstream_response_time](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_response_time).
 
 {{< note >}}Several metrics outlined in [Metrics and Metadata]({{< ref "metrics-metadata" >}}) will only be available if the corresponding variables are included in a custom [access.log](http://nginx.org/en/docs/http/ngx_http_log_module.html) format used for logging requests. You can find a complete list of NGINX log variables [here](http://nginx.org/en/docs/varindex.html).{{< /note >}}
 

content/amplify/nginx-amplify-agent/metadata-metrics-collection.md

@@ -9,7 +9,7 @@ docs: DOCS-964
 F5 NGINX Amplify Agent collects the following types of data:
 
   * **NGINX metrics.** NGINX Amplify Agent collects a lot of NGINX related metrics from [stub_status](http://nginx.org/en/docs/http/ngx_http_stub_status_module.html), the NGINX Plus status API, the NGINX log files, and from the NGINX process state.
-  * **System metrics.** These are various key metrics describing the system, e.g., CPU usage, memory usage, network traffic, etc.
+  * **System metrics.** These are various key metrics describing the system, for example, CPU usage, memory usage, network traffic, etc.
   * **PHP-FPM metrics.** NGINX Amplify Agent can obtain metrics from the PHP-FPM pool status if it detects a running PHP-FPM main process.
   * **MySQL metrics.** NGINX Amplify Agent can obtain metrics from the MySQL global status set of variables.
   * **NGINX metadata.** This is what describes your NGINX instances, and it includes package data, build information, the path to the binary, build configuration options, etc. NGINX metadata also includes the NGINX configuration elements.

content/amplify/user-interface/account-settings.md

@@ -26,7 +26,7 @@ Users can be assigned one of the three roles — Admin, User, or Read-Only. Admi
 
 In the **Notifications** section, you will find information about the emails currently registered with your account and whether they are verified or not. The alert notifications are only sent to verified emails.
 
-In addition to the email alert notifications, you can optionally configure the integration with your Slack team and workspace. Under the registered emails section, select the "Add to Slack" button to allow Amplify to send you certain notifications on Slack. You will have to log in and provide the necessary details about your team and what channels you'd like to add to Amplify notifications. Both direct messages and channels can be used for notifications. If configured successfully, Amplify can send alert information to Slack. A few more additional notifications are available — e.g., F5 NGINX Amplify Agent not finding a running NGINX instance, but also proactive messages about the issues with the SSL certs.
+In addition to the email alert notifications, you can optionally configure the integration with your Slack team and workspace. Under the registered emails section, select the "Add to Slack" button to allow Amplify to send you certain notifications on Slack. You will have to log in and provide the necessary details about your team and what channels you'd like to add to Amplify notifications. Both direct messages and channels can be used for notifications. If configured successfully, Amplify can send alert information to Slack. A few more additional notifications are available — for example, F5 NGINX Amplify Agent not finding a running NGINX instance, but also proactive messages about the issues with the SSL certs.
 
 
 {{< img src="amplify/amplify-notifications.png" alt="Notifications" >}}

content/amplify/user-interface/analyzer.md

@@ -37,14 +37,14 @@ The following information is provided when a report is generated from an NGINX c
     * Typical configuration issues highlighted
     * Common advice about proxy configurations
     * Suggestions about simplifying rewrites for certain use cases
-    * Key security measures (e.g., *stub_status* is unprotected)
+    * Key security measures (for example, *stub_status* is unprotected)
     * Typical errors in configuring locations, especially with *regex*
 
 To parse SSL certificate metadata, NGINX Amplify Agent uses standard OpenSSL(1) functions. SSL certificates are parsed and analyzed only when the corresponding [settings]({{< ref "/amplify/user-interface/account-settings" >}}) are turned on. SSL certificate analysis is *off* by default.
 
 Static analysis will only include information about specific issues with the NGINX configuration if those are found in your NGINX setup.
 
-In the future, the **Analyzer** page will also include *dynamic analysis*, effectively linking the observed NGINX behavior to its configuration — e.g., when it makes sense to increase or decrease certain parameters like [proxy_buffers](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers), etc.
+In the future, the **Analyzer** page will also include *dynamic analysis*, effectively linking the observed NGINX behavior to its configuration — for example, when it makes sense to increase or decrease certain parameters like [proxy_buffers](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers), etc.
 
 {{< note >}} Config analysis is *on* by default. If you don't want your NGINX configuration to be checked, unset the corresponding setting in either Global, or Local (per-system) settings. See [**Settings**]({{< ref "/amplify/user-interface/account-settings" >}}). {{< /note >}}