Merge pull request #4734 from marcduiker/upgrade-hugo-docsy

Upgrade hugo docsy for 1.16

Author: marcduiker

.github/workflows/website-v1-15.yml renamed to .github/workflows/website-v1-16.yml

@@ -1,14 +1,14 @@
-name: Azure Static Web App v1.15
+name: Azure Static Web App v1.16
 
 on:
   workflow_dispatch:
   push:
     branches:
-      - v1.15
+      - v1.16
   pull_request:
     types: [opened, synchronize, reopened, closed]
     branches:
-      - v1.15
+      - v1.16
 
 jobs:
   build_and_deploy_job:
@@ -47,7 +47,7 @@ jobs:
           HUGO_ENV: production
           HUGO_VERSION: "0.147.9"
         with:
-          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_V1_15 }}
+          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_V1_16 }}
           repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
           skip_deploy_on_missing_secrets: true
           action: "upload"
@@ -66,6 +66,6 @@ jobs:
         id: closepullrequest
         uses: Azure/static-web-apps-deploy@v1
         with:
-          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_V1_15 }}
+          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_V1_16 }}
           skip_deploy_on_missing_secrets: true
           action: "close"

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md

@@ -112,6 +112,8 @@ The code examples below leverage Dapr SDKs to invoke the output bindings endpoin
 
 Here's an example of using a console app with top-level statements in .NET 6+:
 
+Here's an example of using a console app with top-level statements in .NET 6+:
+
 ```csharp
 using System.Text;
 using System.Threading.Tasks;

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md

@@ -121,6 +121,8 @@ Below are code examples that leverage Dapr SDKs to demonstrate an input binding.
 
 The following example demonstrates how to configure an input binding using ASP.NET Core controllers.
 
+The following example demonstrates how to configure an input binding using ASP.NET Core controllers.
+
 ```csharp
 using System.Collections.Generic;
 using System.Threading.Tasks;

daprdocs/content/en/developing-applications/building-blocks/jobs/jobs-features-concepts.md

@@ -15,20 +15,19 @@ into the features and concepts included with Dapr Jobs and the various SDKs. Dap
 
 ## Job identity
 
-All jobs are registered with a case-sensitive job name. These names are intended to be unique across all services 
-interfacing with the Dapr runtime. The name is used as an identifier when creating and modifying the job as well as 
+All jobs are registered with a case-sensitive job name. These names are intended to be unique across all services
+interfacing with the Dapr runtime. The name is used as an identifier when creating and modifying the job as well as
 to indicate which job a triggered invocation is associated with.
 
-Only one job can be associated with a name at any given time. Any attempt to create a new job using the same name
-as an existing job will result in an overwrite of this existing job.
+Only one job can be associated with a name at any given time. By default, any attempt to create a new job using the same name as an existing job results in an error. However, if the `overwrite` flag is set to `true`, the new job overwrites the existing job with the same name.
 
 ## Scheduling Jobs
 A job can be scheduled using any of the following mechanisms:
 - Intervals using Cron expressions, duration values, or period expressions
 - Specific dates and times
 
-For all time-based schedules, if a timestamp is provided with a time zone via the RFC3339 specification, that 
-time zone is used. When not provided, the time zone used by the server running Dapr is used. 
+For all time-based schedules, if a timestamp is provided with a time zone via the RFC3339 specification, that
+time zone is used. When not provided, the time zone used by the server running Dapr is used.
 In other words, do **not** assume that times run in UTC time zone, unless otherwise specified when scheduling
 the job.
 
@@ -48,7 +47,7 @@ fields spanning the values specified in the table below:
 
 ### Schedule using a duration value
 You can schedule jobs using [a Go duration string](https://pkg.go.dev/time#ParseDuration), in which
-a string consists of a (possibly) signed sequence of decimal numbers, each with an optional fraction and a unit suffix. 
+a string consists of a (possibly) signed sequence of decimal numbers, each with an optional fraction and a unit suffix.
 Valid time units are `"ns"`, `"us"`, `"ms"`, `"s"`, `"m"`, or `"h"`.
 
 #### Example 1
@@ -70,7 +69,7 @@ The following period expressions are supported. The "@every" expression also acc
 | @hourly | Run once an hour at the beginning of the hour | 0 0 * * * * |
 
 ### Schedule using a specific date/time
-A job can also be scheduled to run at a particular point in time by providing a date using the 
+A job can also be scheduled to run at a particular point in time by providing a date using the
 [RFC3339 specification](https://www.rfc-editor.org/rfc/rfc3339).
 
 #### Example 1
@@ -107,15 +106,17 @@ In this setup, you have full control over how triggered jobs are received and pr
 through this gRPC method.
 
 ### HTTP
-If a gRPC server isn't registered with Dapr when the application starts up, Dapr instead triggers jobs by making a 
+If a gRPC server isn't registered with Dapr when the application starts up, Dapr instead triggers jobs by making a
 POST request to the endpoint `/job/<job-name>`. The body includes the following information about the job:
 - `Schedule`: When the job triggers occur
 - `RepeatCount`: An optional value indicating how often the job should repeat
 - `DueTime`: An optional point in time representing either the one time when the job should execute (if not recurring)
 or the not-before time from which the schedule should take effect
 - `Ttl`: An optional value indicating when the job should expire
 - `Payload`: A collection of bytes containing data originally stored when the job was scheduled
+- `Overwrite`: A flag to allow the requested job to overwrite an existing job with the same name, if it already exists.
+- `FailurePolicy`: An optional failure policy for the job.
 
 The `DueTime` and `Ttl` fields will reflect an RC3339 timestamp value reflective of the time zone provided when the job was
 originally scheduled. If no time zone was provided, these values indicate the time zone used by the server running
-Dapr.
+Dapr.

daprdocs/content/en/developing-applications/building-blocks/jobs/jobs-overview.md

@@ -53,11 +53,11 @@ Dapr's jobs API ensures the tasks represented in these scenarios are performed c
 
 ## Features
 
-The jobs API provides several features to make it easy for you to schedule jobs.
+The main functionality of the Jobs API allows you to create, retrieve, and delete scheduled jobs. By default, when you create a job with a name that already exists, the operation fails unless you explicitly set the `overwrite` flag to `true`. This ensures that existing jobs are not accidentally modified or overwritten.
 
 ### Schedule jobs across multiple replicas
 
-When you create a job, it replaces any existing job with the same name. This means that every time a job is created, it resets the count and only keeps 1 record in the embedded etcd for that job. Therefore, you don't need to worry about multiple jobs being created and firing off — only the most recent job is recorded and executed, even if all your apps schedule the same job on startup. 
+When you create a job, it does not replace an existing job with the same name, unless you explicitly set the `overwrite` flag. This means that every time a job is created, it resets the count and only keeps 1 record in the embedded etcd for that job. Therefore, you don't need to worry about multiple jobs being created and firing off — only the most recent job is recorded and executed, even if all your apps schedule the same job on startup. 
 
 The Scheduler service enables the scheduling of jobs to scale across multiple replicas, while guaranteeing that a job is only triggered by 1 Scheduler service instance. 
 

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md

@@ -624,6 +624,29 @@ await context.CallActivityAsync("PostResults", sum);
 
 {{< /tabpane >}}
 
+With the release of 1.16, it's even easier to process workflow activities in parallel while putting an upper cap on 
+concurrency by using the following extension methods on the `WorkflowContext`:
+
+{{% tabpane %}}
+
+{{% tab header=".NET" %}}
+<!-- .NET -->
+```csharp
+//Revisiting the earlier example...
+// Get a list of work items to process
+var workBatch = await context.CallActivityAsync<object[]>("GetWorkBatch", null);
+
+// Process deterministically in parallel with an upper cap of 5 activities at a time
+var results = await context.ProcessInParallelAsync(workBatch, workItem => context.CallActivityAsync<int>("ProcessWorkItem", workItem), maxConcurrency: 5);
+
+var sum = results.Sum(t => t);
+await context.CallActivityAsync("PostResults", sum);
+```
+
+{{% /tab %}}
+
+{{% /tabpane %}}
+
 Limiting the degree of concurrency in this way can be useful for limiting contention against shared resources. For example, if the activities need to call into external resources that have their own concurrency limits, like a databases or external APIs, it can be useful to ensure that no more than a specified number of activities call that resource concurrently.
 
 ## Async HTTP APIs

daprdocs/content/en/operations/hosting/kubernetes/kubernetes-persisting-scheduler.md

@@ -77,6 +77,14 @@ kubectl delete pvc -n dapr-system dapr-scheduler-data-dir-dapr-scheduler-server-
 Persistent Volume Claims are not deleted automatically with an [uninstall]({{% ref dapr-uninstall.md %}}). This is a deliberate safety measure to prevent accidental data loss.
 {{% /alert %}}
 
+{{% alert title="Note" color="primary" %}}
+For storage providers that do NOT support dynamic volume expansion: If Dapr has ever been installed on the cluster before, the Scheduler's Persistent Volume Claims must be manually uninstalled in order for new ones with increased storage size to be created.
+```bash
+kubectl delete pvc -n dapr-system dapr-scheduler-data-dir-dapr-scheduler-server-0 dapr-scheduler-data-dir-dapr-scheduler-server-1 dapr-scheduler-data-dir-dapr-scheduler-server-2
+```
+Persistent Volume Claims are not deleted automatically with an [uninstall]({{< ref dapr-uninstall.md >}}). This is a deliberate safety measure to prevent accidental data loss.
+{{% /alert %}}
+
 #### Increase existing Scheduler Storage Size
 
 {{% alert title="Warning" color="warning" %}}

daprdocs/content/en/reference/api/jobs_api.md

@@ -37,6 +37,8 @@ Parameter | Description
 `dueTime` | An optional time at which the job should be active, or the "one shot" time, if other scheduling type fields are not provided. Accepts a "point in time" string in the format of RFC3339, Go duration string (calculated from creation time), or non-repeating ISO8601.
 `repeats` | An optional number of times in which the job should be triggered. If not set, the job runs indefinitely or until expiration.
 `ttl` | An optional time to live or expiration of the job. Accepts a "point in time" string in the format of RFC3339, Go duration string (calculated from job creation time), or non-repeating ISO8601.
+`overwrite` | A boolean value to specify if the job can overwrite an existing one with the same name. Default value is `false`
+`failure_policy` | An optional failure policy for the job. Details of the format are below. If not set, the job is retried up to 3 times with a delay of 1 second between retries.
 
 #### schedule
 `schedule` accepts both systemd timer-style cron expressions, as well as human readable '@' prefixed period strings, as defined below.
@@ -62,6 +64,39 @@ Entry                  | Description                                | Equivalent
 @daily (or @midnight)  | Run once a day, midnight                   | 0 0 0 * * *
 @hourly                | Run once an hour, beginning of hour        | 0 0 * * * *
 
+#### failure_policy
+
+`failure_policy` specifies how the job should handle failures.
+
+It can be set to `constant` or `drop`.
+- The `constant` policy retries the job constantly with the following configuration options.
+  - `max_retries` configures how many times the job should be retried. Defaults to retrying indefinitely. `nil` denotes unlimited retries, while `0` means the request will not be retried.
+  - `interval` configures the delay between retries. Defaults to retrying immediately. Valid values are of the form `200ms`, `15s`, `2m`, etc.
+- The `drop` policy drops the job after the first failure, without retrying.
+
+##### Example 1
+
+```json
+{
+  //...
+  "failure_policy": {
+    "constant": {
+      "max_retries": 3,
+      "interval": "10s"
+    }
+  }
+}
+```
+##### Example 2
+
+```json
+{
+  //...
+  "failure_policy": {
+    "drop": {}
+  }
+}
+```
 
 ### Request body
 

daprdocs/content/en/reference/components-reference/supported-bindings/gcpbucket.md

@@ -82,8 +82,13 @@ This component supports **output binding** with the following operations:
 
 - `create` : [Create file](#create-file)
 - `get` : [Get file](#get-file)
+- `bulkGet` : [Bulk get objects](#bulk-get-objects)
 - `delete` : [Delete file](#delete-file)
 - `list`: [List file](#list-files)
+- `copy`: [Copy file](#copy-files)
+- `move`: [Move file](#move-files)
+- `rename`: [Rename file](#rename-files)
+
 
 ### Create file
 
@@ -216,6 +221,72 @@ The metadata parameters are:
 
 The response body contains the value stored in the object.
 
+### Bulk get objects
+
+To perform a bulk get operation that retrieves all bucket files at once, invoke the GCP bucket binding with a `POST` method and the following JSON body:
+
+```json
+{
+  "operation": "bulkGet",
+}
+```
+
+The metadata parameters are:
+
+- `encodeBase64` - (optional) configuration to encode base64 file content before return the content for all files
+
+#### Example
+
+{{% tabpane text=true %}}
+
+  {{% tab header="Windows" %}}
+  ```bash
+  curl -d '{ \"operation\": \"bulkget\"}' http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
+  ```
+  {{% /tab %}}
+
+  {{% tab header="Linux" %}}
+  ```bash
+  curl -d '{ "operation": "bulkget"}' \
+        http://localhost:<dapr-port>/v1.0/bindings/<binding-name>
+  ```
+  {{% /tab %}}
+
+{{% /tabpane %}}
+
+#### Response
+
+The response body contains an array of objects, where each object represents a file in the bucket with the following structure:
+
+```json
+[
+  {
+    "name": "file1.txt",
+    "data": "content of file1",
+    "attrs": {
+      "bucket": "mybucket",
+      "name": "file1.txt",
+      "size": 1234,
+      ...
+    }
+  },
+  {
+    "name": "file2.txt",
+    "data": "content of file2",
+    "attrs": {
+      "bucket": "mybucket",
+      "name": "file2.txt",
+      "size": 5678,
+      ...
+    }
+  }
+]
+```
+
+Each object in the array contains:
+- `name`: The name of the file
+- `data`: The content of the file
+- `attrs`: Object attributes from GCP Storage including metadata like creation time, size, content type, etc.
 
 ### Delete object
 
@@ -262,7 +333,7 @@ An HTTP 204 (No Content) and empty body will be retuned if successful.
 
 ### List objects
 
-To perform a list object operation, invoke the S3  binding with a `POST` method and the following JSON body:
+To perform a list object operation, invoke the GCP bucket binding with a `POST` method and the following JSON body:
 
 ```json
 {
@@ -321,6 +392,58 @@ The list of objects will be returned as JSON array in the following form:
 	}
 ]
 ```
+
+### Copy objects
+
+To perform a copy object operation, invoke the GCP bucket binding with a `POST` method and the following JSON body:
+
+```json
+{
+  "operation": "copy",
+  "metadata": {
+    "destinationBucket": "destination-bucket-name",
+  }
+}
+```
+
+The metadata parameters are:
+
+- `destinationBucket` - the name of the destination bucket (required)
+
+### Move objects
+
+To perform a move object operation, invoke the GCP bucket binding with a `POST` method and the following JSON body:
+
+```json
+{
+  "operation": "move",
+  "metadata": {
+    "destinationBucket": "destination-bucket-name",
+  }
+}
+```
+
+The metadata parameters are:
+
+- `destinationBucket` - the name of the destination bucket (required)
+
+### Rename objects
+
+To perform a rename object operation, invoke the GCP bucket binding with a `POST` method and the following JSON body:
+
+```json
+{
+  "operation": "rename",
+  "metadata": {
+    "newName": "object-new-name",
+  }
+}
+```
+
+The metadata parameters are:
+
+- `newName` - the new name of the object (required)
+
 ## Related links
 
 - [Basic schema for a Dapr component]({{% ref component-schema %}})