Merge branch 'main' into ngf-release-2.0

Author: ADubhlaoich

.cloudcannon/initial-site-settings.json

@@ -0,0 +1,23 @@
+{
+   "ssg": "hugo",
+   "mode": "hosted",
+   "build": {
+     "install_command": "[ -f package.json ] && npm i",
+     "build_command": "hugo --destination public --baseURL / --noTimes",
+     "output_path": "public",
+     "environment_variables": [
+       {
+         "key": "HUGO_CACHEDIR",
+         "value": "/usr/local/__site/src/.hugo_cache/"
+       }
+     ],
+     "preserved_paths": "node_modules/,.hugo_cache/,resources/",
+     "preserve_output": false,
+     "include_git": true,
+     "manually_configure_urls": false,
+     "hugo_version": "0.134.3",
+     "ruby_version": "2.7.3",
+     "node_version": "18",
+     "deno_version": "1.40.2"
+   }
+}

.cloudcannon/schemas/nms/policy.md

@@ -153,7 +153,7 @@ Confirm the policy is being enforced:
 
 <!-- Add troubleshooting steps for issues users might encounter and can self-solve. The purpose of this section is to deflect customer calls to Support. -->
 
-For help resolving common issues when setting up and configuring the policy, follow the steps in this section. If you cannot find a solution to your specific issue, reach out to [NGINX Customer Support]({{< relref "support/contact-support.md" >}}) for assistance.
+For help resolving common issues when setting up and configuring the policy, follow the steps in this section. If you cannot find a solution to your specific issue, reach out to [NGINX Customer Support]({{< ref "support/contact-support.md" >}}) for assistance.
 
 ### Issue 1
 

.gitattributes

@@ -1,4 +1,5 @@
 # Set the default behavior for correcting line endings, 
 # in case people don't have core.autocrlf set.
 * text=auto
-
+.github/workflows/update_from_nginx_documentation.yml merge=ours
+.gitattributes merge=ours

.github/ISSUE_TEMPLATE/feature_request.md renamed to .github/ISSUE_TEMPLATE/1-feature_request.md

@@ -0,0 +1,24 @@
+---
+name: Story task
+about: This template is for a story or task, encompassing a single work item for completion
+title: ""
+labels: "documentation"
+projects: ["nginxinc/32"]
+assignees: ""
+---
+
+*Remove italicized directions as relevant to reduce noise in the issue description.*
+
+## Overview
+
+*Written as a user story*.
+
+**As a** <user>, **I want** <thing>, **So I can** <action>.
+
+## Description
+
+*Add the finer details of what this task involves and is trying to accomplish. A problem well defined is half-solved*.
+
+## Acceptance criteria
+
+*Add any exacting acceptance criteria for the task to be complete. Start with known hard requirements, since they may create blockers.*

.github/ISSUE_TEMPLATE/bug_report.md renamed to .github/ISSUE_TEMPLATE/2-bug_report.md

@@ -0,0 +1,40 @@
+---
+name: Epic overview
+about: This template is for planning an epic, which is a large body of effort involving multiple stories or tasks
+title: ""
+labels: "epic, documentation"
+projects: ["nginxinc/32"]
+assignees: ""
+---
+
+*Remove italicized directions as relevant to reduce noise in the issue description.*
+
+## Description
+
+*Write a high-level description of what the body of work for this epic includes.*
+
+## Goals
+
+*Describe the intent of the epic and what the intended impact is for this effort.*
+
+## User stories
+
+*Add a user story for relevant persona to this epic, who are the stakeholders*.
+
+**As a** <user>,
+**I want** <thing>,
+**So I can** <action>.
+
+**As a** <user>,
+**I want** <thing>,
+**So I can** <action>.
+
+## Tasks
+
+*Create a simple list of tasks necessary for this epic. Finer details should be kept to sub-issues/tasks/stories.*
+
+- Example task 1
+- Example task 1
+- Example task 1
+- Example task 1
+- Example task 1

.github/ISSUE_TEMPLATE/3-story_task.md

@@ -0,0 +1,44 @@
+---
+name: Content release plan
+about: This template is for a content release plan, typically tied to a product release
+title: " v#.# content release plan"
+labels: "documentation"
+projects: ["nginxinc/32"]
+assignees: ""
+---
+
+*Remove italicized directions as relevant to reduce noise in the issue description.*
+
+## Overview
+
+- **Product name**: 
+- **Release date**: 
+
+A content release plan establishes and tracks the documentation work for a product related to a release. 
+
+Add tickets to this content release plan as sub-issues, and update it as you go along.
+
+## Description
+
+*Write a high-level summary of changes expected in this release*.
+
+## User stories
+
+**As a** technical writer, 
+**I want** a content release plan for my product, 
+**So I can** ensure correct content is released alongside the latest version of the product. 
+
+**As a** product owner, 
+**I want** a content release plan for my product, 
+**So I can** ensure the product team includes documentation as part of changes to the product. 
+
+## Tasks
+
+*Create a simple list of tasks necessary for this content plan. Finer details can be kept to sub-issues.*
+*Each task item should have a 1:1 relationship with a documentation item, which could be an engineering issue.*
+
+- [ ] Update changelog/release notes
+- [ ] Update version reference information (Such as technical specifications, version shortcodes)
+- [ ] Update any other documentation impacted by changes in this release
+- Additional task 1
+- Additional task 2

.github/ISSUE_TEMPLATE/4-epic_overview.md

@@ -25,6 +25,6 @@ jobs:
         uses: actions/checkout@85e6279cec87321a52edac9c87bce653a07cf6c2 # v4.2.2
 
       - name: Scan
-        uses: fossas/fossa-action@93a52ecf7c3ac7eb40f5de77fd69b1a19524de94 # v1.5.0
+        uses: fossas/fossa-action@c0a7d013f84c8ee5e910593186598625513cc1e4 # v1.6.0
         with:
           api-key: ${{ secrets.FOSSA_TOKEN }}

.github/ISSUE_TEMPLATE/5-content_plan.md

@@ -42,7 +42,7 @@ jobs:
             }
 
       - name: Send notification
-        uses: 8398a7/action-slack@28ba43ae48961b90635b50953d216767a6bea486 # v3.16.2
+        uses: 8398a7/action-slack@1750b5085f3ec60384090fb7c52965ef822e869e # v3.18.0
         with:
           status: custom
           custom_payload: |

.github/workflows/fossa.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@6bb031afdd8eb862ea3fc1848194185e076637e5 # v3.28.11
+        uses: github/codeql-action/upload-sarif@1b549b9259bda1cb5ddde3b41741a82a2d15a841 # v3.28.13
         with:
           sarif_file: results.sarif

.github/workflows/notification.yml

@@ -0,0 +1,67 @@
+# Contributing guidelines for closed content
+
+This document describes the process for authoring "closed content", which is content of a sensitive nature that cannot be publicised before release.
+
+Sensitive content might include:
+
+- Security content, including personally identifying information (PII).
+- Content / features that are not yet ready to be announced.
+
+We work in public by default, so this process should only be used on a case by case basis by F5 employees. 
+
+For standard content releases, review the [Contributing guidelines](/CONTRIBUTING.md).
+
+## Overview
+
+This repository (https://github.com/nginx/documentation) is where we work by default. It has a one-way sync to an internal repository, used for closed content.
+
+The process is as follows:
+
+- Add the closed repository as a remote
+- Create a remote branch with the prefix `internal/` in the closed repository
+- Open a pull request in the closed repository to get previews and request feedback
+- Once all stakeholders are happy with changes, close the pull request in the closed repository
+- Merge the changes from the remote (Closed) repository branch with a new branch in the open repository
+- Open a new pull request in the open repository, where it can be merged
+
+You can get the URL through our internal communication channels: it will be represented in the following steps as `<closed-URL>`.
+
+## Steps
+
+To create closed content, add the closed repository as a remote to the main repository, then fetch.
+
+```shell
+cd documentation
+git remote add internal git@github.com:<closed-url>.git
+git fetch
+```
+
+Check out the remote `main` branch, and use it to create a feature branch. **Ensure that you prefix all branch names with `internal/`**
+
+```shell
+git checkout internal/main
+git checkout -b internal/feature
+```
+
+Once you've finished with your work, commit it and push it to the internal repository:
+
+```shell
+git add .
+git commit
+git push internal
+```
+
+Open a pull request when you are ready to receive feedback from stakeholders.
+
+After any iterative work, close the pull request. Since the closed repository is a mirror of the open one, we do not merge changes to it.
+
+Change back to the origin `main` branch, create a new branch, merge your internal branch and push to origin.
+
+```shell
+git checkout main
+git checkout -b feature
+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.

.github/workflows/ossf_scorecard.yml

@@ -15,7 +15,7 @@ If you are an F5 employee, see the following additional guidance [For F5 Employe
   - Review our Documentation [style guide](./templates/style-guide.md)
   - Review our [Contributing guidelines for writers](./CONTRIBUTING_DOCS.md)
 - [Issue Lifecycle](#issue-lifecycle)
-- [Content edited elsewhere](#content-edited-elsewhere)
+- [Additional NGINX documentation](#additional-nginx-documentation)
 - [F5 Contributor License Agreement (CLA)](#f5-contributor-license-agreement)
 
 ## Report a bug
@@ -92,7 +92,6 @@ This repository does not include all of the source content for the NGINX documen
 - [nginx.org](https://github.com/nginx/nginx.org) - source for https://nginx.org
 - [NGINX Unit](https://github.com/nginx/unit) - source for https://unit.nginx.org
 - [NGINX Ingress Controller](https://github.com/nginxinc/kubernetes-ingress/) - source for https://docs.nginx.com/nginx-ingress-controller
-- [NGINX Agent](https://github.com/nginx/agent) - source for https://docs.nginx.com/nginx-agent
 
 In those repositories, you can find documentation source code in the `docs` or `site` subdirectories.
 

CLOSED_CONTRIBUTIONS.md

@@ -16,14 +16,13 @@ If you're an employee of F5/NGINX, also read [For F5/NGINX Employees](./F5-NGINX
 You will need to install Hugo _or_ Docker to build and preview docs in your local development environment.
 Refer to the [Hugo installation instructions](https://gohugo.io/getting-started/installing/) for more information.
 
-**NOTE**: We are currently running [Hugo v0.134.2](https://github.com/gohugoio/hugo/releases/tag/v0.134.2) in production.
-
 
 Although not a strict requirement, markdown-link-check is also used in documentation development.
 
 If you have [Docker](https://www.docker.com/get-started/) installed, there are fallbacks for all requirements in the [Makefile](Makefile), meaning you don't need to install them.
 
 - [Installing Hugo](https://gohugo.io/getting-started/installing/)
+  - **NOTE**: We are currently running [Hugo v0.134.2](https://github.com/gohugoio/hugo/releases/tag/v0.134.2) in production.
 - [Installing markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli?tab=readme-ov-file#installation)
 - [Installing markdown-link-check](https://github.com/tcort/markdown-link-check?tab=readme-ov-file#installation).
 
@@ -35,7 +34,11 @@ The configuration files are as follows:
 
 ## Local Docs Development
 
-To build the documentation locally, use the `make` command in the documentation folder with these targets:
+To build the documentation locally, use the `make` command in the documentation folder. First make sure you have the latest version of our Hugo theme with:
+
+`make hugo-update`
+
+Once you've updated the theme, you can use these targets:
 
 ```text
 make watch        - Runs a local Hugo server, allowing for changes to be previewed in a  browser.
@@ -88,7 +91,7 @@ Here are two examples:
 
 ```md
 To install <software>, refer to the [installation instructions]({{< ref "install.md" >}}).
-To install <integation>, refer to the [integration instructions]({{< relref "/integration/thing.md#section" >}}).
+To install <integation>, refer to the [integration instructions]({{< ref "/integration/thing.md#section" >}}).
 ```
 
 ### How to add images

CONTRIBUTING.md

@@ -1,20 +1,18 @@
 # For F5/NGINX Employees
 
-This repository is a functional mirror. We want to do as much of our work as possible in the
-public repository. However, if you are working with:
+This repository is public, and we do as much of our work as possible in the public as a commitment to open source.
 
-- Security content, including personally identifying information (PII).
-- Content / features that are not yet ready to be announced.
+Before new content is published at https://docs.nginx.com, it must be committed to this `documentation` repository. 
 
-Before new content is published at https://docs.nginx.com, it must be written to this `documentation` repository. After you get approvals in the internal `docs` repository, you'll need to create a _second_ pull request in this open `documentation` repository.
+If you are an F5 employee unable to assign yourself as an owner of an issue or a reviewer of a pull request, ask a member of the NGINX documentation team for help.
 
-If you are unable to assign yourself as an owner of an issue or a reviewer of a pull request, and are an employee of F5, ask a member of the NGINX documentation team for help.
+If your content cannot be publicized before release, it is handled differently: read the [Contributing guidelines for closed content](/CLOSED_CONTRIBUTIONS.md) document.
 
-We encourage you to work with community contributors. If you participate in
-PRs, issues, discussions, and more, follow these guidelines:
+We encourage you to work with community contributors. If you participate in PRs, issues, discussions, and more, follow these guidelines:
 
 - Follow the [Code of Conduct](./CODE_OF_CONDUCT.md).
 - Be helpful. We want to encourage people who contribute to continue.
+  - If you need to say "no," here's [an example](https://github.com/nginx/documentation/pull/307#issuecomment-2748521932) of how we interact with the community.
 - Avoid references and links to internal content. 
 - Do not include information about future releases, changes, or features, unless
   specifically authorized.

CONTRIBUTING_DOCS.md

@@ -1,9 +1,8 @@
 ---
-title: "NGINX Agent"
-description: "NGINX Agent is a companion daemon for your NGINX Open Source or NGINX Plus instance."
-linkTitle: "NGINX Agent"
-menu: docs
+title: NGINX Agent
+description: NGINX Agent is a companion daemon for your NGINX Open Source or NGINX
+  Plus instance.
 url: /nginx-agent/
 cascade:
-  logo: "NGINX-product-icon.png"
----
+  logo: NGINX-product-icon.png
+---

F5-NGINX-team-notes.md

@@ -1,8 +1,6 @@
 ---
-title: "Configuration"
-description: "Learn how to configure NGINX Agent."
-linkTitle: "Configuration"
-weight: "400"
-menu: docs
+title: Configuration
+description: Learn how to configure NGINX Agent.
+weight: 400
 url: /nginx-agent/configuration/
----
+---

content/agent/_index.md

@@ -1,12 +1,11 @@
 ---
-title: "Basic configuration"
+title: Basic configuration
 draft: false
 weight: 100
 toc: true
-tags: [ "docs" ]
-docs: "DOCS-1229"
-categories: ["configuration"]
-doctypes: ["task"]
+docs: DOCS-1229
+type:
+- how-to
 ---
 
 The following sections explain how to configure NGINX Agent using configuration files, CLI flags, and environment variables.

content/agent/configuration/_index.md

@@ -1,11 +1,10 @@
 ---
-title: "Features configuration"
+title: Features configuration
 draft: false
 weight: 150
 toc: true
-tags: [ "docs" ]
-categories: ["configuration"]
-doctypes: ["task"]
+type:
+- how-to
 ---
 
 ## Overview