Added build caching and build watch paths for Workers and updated the same pages for Pages

Author: aninibread

src/content/docs/pages/ci-cd/builds/build-caching.mdx

@@ -18,7 +18,7 @@ To enable build caching in the Cloudflare dashboard:
 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
 2. In Account Home, select **Workers & Pages**.
 3. In **Overview**, select your Pages project.
-4. Go to **Settings** > **Builds & deployments** > **Build cache** and select **Enable build cache**.
+4. Go to **Settings** > **Build** > **Build cache** and select **Enable**.
 
 ### Clear cache
 
@@ -27,8 +27,8 @@ The build cache can be cleared for a project if needed, such as when debugging b
 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
 2. In Account Home, select **Workers & Pages**.
 3. In **Overview**, select your Pages project.
-4. Go to **Settings** > **Builds & deployments** > **Build cache**.
-5. Select **Clear cache** to clear the build cache.
+4. Go to **Settings** > **Build** > **Build cache**.
+5. Select **Clear Cache** to clear the build cache.
 
 ## How build caching works
 
@@ -58,11 +58,7 @@ Caching the build output from frameworks can speed up subsequent build times. Th
 
 ## Limits
 
-During this beta period, the following limits are imposed:
+The following limits are imposed for build caching:
 
 - **Retention**: Cache is purged seven days after its last read date. Unread cache artifacts are purged seven days after creation.
 - **Storage**: Every project is allocated 10 GB. If the project cache exceeds this limit, the project will automatically start deleting artifacts that were read least recently.
-
-## Feedback
-
-If there are package managers or frameworks you want to see supported, let us know in the Pages channel of the [Cloudflare Developer Discord](https://discord.com/invite/cloudflaredev).

src/content/docs/pages/ci-cd/builds/build-watch-paths.mdx

@@ -1,58 +1,58 @@
 ---
 pcx_content_type: concept
 title: Build watch paths
-
 ---
 
 When you connect a git repository to Pages, by default a change to any file in the repository will trigger a Pages build. You can configure Pages to include or exclude specific paths to specify if Pages should skip a build for a given path. This can be especially helpful if you are using a monorepo project structure and want to limit the amount of builds being kicked off.
 
 ## Configure paths
 
-To configure which paths are included and excluded, go to your Pages project > Settings > Builds & deployments > Build watch paths. Pages will default to setting your project’s includes paths to everything (\[\*]) and excludes paths to nothing (`[]`).
+To configure which paths are included and excluded:
+
+1. In **Overview**, select your Pages project.
+2. Go to **Settings** > **Build** > **Build watch paths**. Pages will default to setting your project’s includes paths to everything (\[\*]) and excludes paths to nothing (`[]`).
 
 The configuration fields can be filled in two ways:
 
-* **Static filepaths**: Enter the precise name of the file you are looking to include or exclude (for example, `docs/README.md`).
-* **Wildcard syntax:** Use wildcards to match multiple path directories. You can specify wildcards at the start or end of your rule.
+- **Static filepaths**: Enter the precise name of the file you are looking to include or exclude (for example, `docs/README.md`).
+- **Wildcard syntax:** Use wildcards to match multiple path directories. You can specify wildcards at the start or end of your rule.
 
 :::note[Wildcard syntax]
 
-
 A wildcard (`*`) is a character that is used within rules. It can be placed alone to match anything or placed at the start or end of a rule to allow for better control over branch configuration. A wildcard will match zero or more characters.For example, if you wanted to match all branches that started with `fix/` then you would create the rule `fix/*` to match strings like `fix/1`, `fix/bugs`or `fix/`.
 
-
 :::
 
 For each path in a push event, build watch paths will be evaluated as follows:
 
-* Paths satisfying excludes conditions are ignored first
-* Any remaining paths are checked against includes conditions
-* If any matching path is found, a build is triggered. Otherwise the build is skipped
+- Paths satisfying excludes conditions are ignored first
+- Any remaining paths are checked against includes conditions
+- If any matching path is found, a build is triggered. Otherwise the build is skipped
 
 Pages will bypass the path matching for a push event and default to building the project if:
 
-* A push event contains 0 file changes, in case a user pushes a empty push event to trigger a build
-* A push event contains 3000+ file changes or 20+ commits
+- A push event contains 0 file changes, in case a user pushes a empty push event to trigger a build
+- A push event contains 3000+ file changes or 20+ commits
 
 ## Examples
 
 ### Example 1
 
 If you want to trigger a build from all changes within a set of directories, such as all changes in the folders `project-a/` and `packages/`
 
-* Include paths: `project-a/*, packages/*`
-* Exclude paths: \`\`
+- Include paths: `project-a/*, packages/*`
+- Exclude paths: \`\`
 
 ### Example 2
 
 If you want to trigger a build for any changes, but want to exclude changes to a certain directory, such as all changes in a docs/ directory
 
-* Include paths: `*`
-* Exclude paths: `docs/*`
+- Include paths: `*`
+- Exclude paths: `docs/*`
 
 ### Example 3
 
 If you want to trigger a build for a specific file or specific filetype, for example all files ending in `.md`.
 
-* Include paths: `*.md`
-* Exclude paths: \`\`
+- Include paths: `*.md`
+- Exclude paths: \`\`

src/content/docs/workers/ci-cd/builds/advanced-setups.mdx

@@ -3,7 +3,7 @@ pcx_content_type: reference
 title: Advanced Setups
 description: Learn how to use Workers Builds with more advanced setups
 sidebar:
-  order: 5
+  order: 7
 ---
 
 ## Monorepos

src/content/docs/workers/ci-cd/builds/build-caching.mdx

@@ -0,0 +1,69 @@
+---
+pcx_content_type: concept
+title: Build caching
+description: Improve build times by caching build outputs and dependencies
+sidebar:
+  order: 5
+---
+
+Improve Workers Builds build times by turning on build caching to restore dependencies and build output between builds. The first build to occur after enabling build caching on your Pages project will save to cache. Every subsequent build will restore from cache unless configured otherwise.
+
+## Configuration
+
+### Enable build caching
+
+To enable build caching in the Cloudflare dashboard:
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
+2. In Account Home, select **Workers & Pages**.
+3. In **Overview**, select your Workers project.
+4. Go to **Settings** > **Build** > **Build cache** and select **Enable**.
+
+### Clear cache
+
+The build cache can be cleared for a project when needed, such as when debugging build issues. To clear the build cache:
+
+1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account.
+2. In Account Home, select **Workers & Pages**.
+3. In **Overview**, select your Workers project.
+4. Go to **Settings** > **Build** > **Build cache**.
+5. Select **Clear Cache** to clear the build cache.
+
+## How build caching works
+
+When enabled, build caching will automatically detect which package manager and framework the project is using from its `package.json` and cache data accordingly for the build.
+
+The following shows which package managers and frameworks are supported for dependency and build output caching respectively.
+
+### Package managers
+
+Workers build cache will cache the global cache directories of the following package managers:
+
+- [yarn](https://yarnpkg.com/)
+- [npm](https://www.npmjs.com/)
+- [pnpm](https://pnpm.io/)
+- [node.js](https://nodejs.org/)
+
+### Frameworks
+
+The following frameworks support build output caching:
+
+| Framework  | Directories cached                            |
+| ---------- | --------------------------------------------- |
+| Astro      | `node_modules/.astro`                         |
+| Docusaurus | `node_modules/.cache`, `.docusaurus`, `build` |
+| Eleventy   | `.cache`                                      |
+| Gatsby     | `.cache`, `public`                            |
+| Next.js    | `.next/cache`                                 |
+| Nuxt       | `node_modules/.cache/nuxt`                    |
+
+:::note
+[Static assets](/workers/static-assets/) and [frameworks](/workers/frameworks/) are now supported in Cloudflare Workers.
+:::
+
+## Limits
+
+The following limits are imposed for build caching:
+
+- **Retention**: Cache is purged 7 days after its last read date. Unread cache artifacts are purged 7 days after creation.
+- **Storage**: Every project is allocated 10 GB. If the project cache exceeds this limit, the project will automatically start deleting artifacts that were read least recently.

src/content/docs/workers/ci-cd/builds/build-watch-paths.mdx

@@ -0,0 +1,61 @@
+---
+pcx_content_type: concept
+title: Build watch paths
+description: Reduce compute for your monorepo by specifying paths for Workers Builds to skip
+sidebar:
+  order: 6
+---
+
+When you connect a git repository to Workers, by default a change to any file in the repository will trigger a build. You can configure Workers to include or exclude specific paths to specify if Workers should skip a build for a given path. This can be especially helpful if you are using a monorepo project structure and want to limit the amount of builds being kicked off.
+
+## Configure paths
+
+To configure which paths are included and excluded:
+
+1. In **Overview**, select your Workers project.
+2. Go to **Settings** > **Build** > **Build watch paths**. Workers will default to setting your project’s includes paths to everything (\[\*]) and excludes paths to nothing (`[]`).
+
+The configuration fields can be filled in two ways:
+
+- **Static filepaths**: Enter the precise name of the file you are looking to include or exclude (for example, `docs/README.md`).
+- **Wildcard syntax:** Use wildcards to match multiple path directories. You can specify wildcards at the start or end of your rule.
+
+:::note[Wildcard syntax]
+
+A wildcard (`*`) is a character that is used within rules. It can be placed alone to match anything or placed at the start or end of a rule to allow for better control over branch configuration. A wildcard will match zero or more characters.For example, if you wanted to match all branches that started with `fix/` then you would create the rule `fix/*` to match strings like `fix/1`, `fix/bugs`or `fix/`.
+
+:::
+
+For each path in a push event, build watch paths will be evaluated as follows:
+
+- Paths satisfying excludes conditions are ignored first
+- Any remaining paths are checked against includes conditions
+- If any matching path is found, a build is triggered. Otherwise the build is skipped
+
+Workers will bypass the path matching for a push event and default to building the project if:
+
+- A push event contains 0 file changes, in case a user pushes a empty push event to trigger a build
+- A push event contains 3000+ file changes or 20+ commits
+
+## Examples
+
+### Example 1
+
+If you want to trigger a build from all changes within a set of directories, such as all changes in the folders `project-a/` and `packages/`
+
+- Include paths: `project-a/*, packages/*`
+- Exclude paths: \`\`
+
+### Example 2
+
+If you want to trigger a build for any changes, but want to exclude changes to a certain directory, such as all changes in a docs/ directory
+
+- Include paths: `*`
+- Exclude paths: `docs/*`
+
+### Example 3
+
+If you want to trigger a build for a specific file or specific filetype, for example all files ending in `.md`.
+
+- Include paths: `*.md`
+- Exclude paths: \`\`

src/content/docs/workers/ci-cd/builds/index.mdx

@@ -3,14 +3,9 @@ pcx_content_type: concept
 title: Builds
 description: Use Workers Builds to integrate with Git and automatically build and deploy your Worker when you merge a pull request
 sidebar:
-<<<<<<< HEAD
-  badge:
-    text: Beta
-=======
   group:
     badge:
       text: Beta
->>>>>>> 512d7f3090a82fbd18235a6ab7048a7378feb0e4
 ---
 
 Workers Builds allows you to connect an existing Worker to a GitHub or GitLab repository to set up automatic builds and deployments for your development workflow. Creating a new Worker from a git repository will be supported soon.

src/content/docs/workers/ci-cd/builds/limits-and-pricing.mdx

@@ -3,7 +3,7 @@ pcx_content_type: concept
 title: Limits & Pricing
 description: Limits & pricing for Workers Builds
 sidebar:
-  order: 6
+  order: 8
 ---
 
 ## Limits

src/content/docs/workers/ci-cd/builds/troubleshoot.mdx

@@ -3,7 +3,7 @@ pcx_content_type: troubleshooting
 title: Troubleshooting
 description: Learn about troubleshooting and known issues in Workers Builds.
 sidebar:
-  order: 7
+  order: 9
 ---
 
 Workers Builds provides build logs for every build started. You can view build logs by navigating to your **Worker project** > **Deployments** > **View Build History** > **View Build**.

src/content/docs/workers/ci-cd/index.mdx

@@ -3,11 +3,7 @@ pcx_content_type: concept
 title: CI/CD
 description: Set up continuous integration and continuous deployment for your Workers.
 sidebar:
-<<<<<<< HEAD
-  order: 7
-=======
   order: 8
->>>>>>> 512d7f3090a82fbd18235a6ab7048a7378feb0e4
 ---
 
 You can set up continuous integration and continuous deployment (CI/CD) for your Workers by using either the native build system, [Workers Builds](#workers-builds), or using [external providers](#external-cicd) to optimize your development workflow.

src/content/docs/workers/configuration/versions-and-deployments/index.mdx

@@ -16,8 +16,6 @@ Using versions and deployments is useful if:
 - You are running critical applications on Workers and want to reduce risk when deploying new versions of your Worker using a rolling deployment strategy.
 - You want to monitor for performance differences when deploying new versions of your Worker.
 - You have a CI/CD pipeline configured for Workers but want to cut manual releases.
-<<<<<<< HEAD
-=======
 
 :::note
 
@@ -26,7 +24,6 @@ Versions and deployments are in **beta and under active development**. Refer to
 Provide your feedback on versions and deployments through the [feedback form](https://www.cloudflare.com/lp/developer-week-deployments).
 
 :::
->>>>>>> 512d7f3090a82fbd18235a6ab7048a7378feb0e4
 
 ## Versions