mirror of https://github.com/dapr/docs.git
Merge branch 'v1.14' into issue_4223-2
This commit is contained in:
Mark Fussell
GitHub
commit
43aa59020d
|
|
@ -7,7 +7,7 @@ description: >
|
|||
How Dapr compares to and works with service meshes
|
||||
---
|
||||
|
||||
Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others?
|
||||
Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and [distributed tracing](https://middleware.io/blog/what-is-distributed-tracing/). This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others?
|
||||
|
||||
## How Dapr and service meshes compare
|
||||
While Dapr and service meshes do offer some overlapping capabilities, **Dapr is not a service mesh**, where a service mesh is defined as a *networking* service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric.
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ spec:
|
|||
allowedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}).
|
||||
The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}).
|
||||
|
||||
## Scenario 3: Deny access to certain sensitive secrets in a secret store
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ spec:
|
|||
deniedSecrets: ["secret1", "secret2"]
|
||||
```
|
||||
|
||||
This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}).
|
||||
This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}).
|
||||
|
||||
## Permission priority
|
||||
|
||||
|
|
|
|||
|
|
@ -61,27 +61,28 @@ Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar the
|
|||
metadata:
|
||||
name: myresiliency
|
||||
scopes:
|
||||
- checkout
|
||||
|
||||
- order-processor
|
||||
|
||||
spec:
|
||||
policies:
|
||||
retries:
|
||||
retryForever:
|
||||
policy: constant
|
||||
maxInterval: 5s
|
||||
maxRetries: -1
|
||||
|
||||
duration: 5s
|
||||
maxRetries: -1
|
||||
|
||||
circuitBreakers:
|
||||
simpleCB:
|
||||
maxRequests: 1
|
||||
timeout: 5s
|
||||
timeout: 5s
|
||||
trip: consecutiveFailures >= 5
|
||||
|
||||
|
||||
targets:
|
||||
apps:
|
||||
order-processor:
|
||||
retry: retryForever
|
||||
circuitBreaker: simpleCB
|
||||
components:
|
||||
statestore:
|
||||
outbound:
|
||||
retry: retryForever
|
||||
circuitBreaker: simpleCB
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,10 +7,10 @@ description: Get started with the Dapr Workflow building block
|
|||
---
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}).
|
||||
Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}).
|
||||
{{% /alert %}}
|
||||
|
||||
Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
||||
Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
||||
|
||||
In this guide, you'll:
|
||||
|
||||
|
|
@ -29,8 +29,8 @@ Select your preferred language-specific Dapr SDK before proceeding with the Quic
|
|||
The `order-processor` console app starts and manages the `order_processing_workflow`, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks:
|
||||
|
||||
- `notify_activity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when:
|
||||
- You have insufficient inventory
|
||||
- Your payment couldn't be processed, etc.
|
||||
- You have insufficient inventory
|
||||
- Your payment couldn't be processed, etc.
|
||||
- `process_payment_activity`: Processes and authorizes the payment.
|
||||
- `verify_inventory_activity`: Checks the state store to ensure there is enough inventory present for purchase.
|
||||
- `update_inventory_activity`: Removes the requested items from the state store and updates the store with the new remaining inventory value.
|
||||
|
|
@ -71,10 +71,11 @@ pip3 install -r requirements.txt
|
|||
In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
|
||||
|
||||
```bash
|
||||
cd workflows/python/sdk
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -105,7 +106,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -122,9 +123,10 @@ When you ran `dapr run -f .`:
|
|||
1. The `NotifyActivity` workflow activity sends a notification saying that order `f4e1926e-3721-478d-be8a-f5bebd1995da` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/app.py`
|
||||
#### `order-processor/app.py`
|
||||
|
||||
In the application's program file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -276,7 +278,6 @@ The `order-processor` console app starts and manages the lifecycle of an order p
|
|||
- `processPaymentActivity`: Processes and authorizes the payment.
|
||||
- `updateInventoryActivity`: Updates the state store with the new remaining inventory value.
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
|
@ -318,11 +319,11 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M
|
|||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
```
|
||||
```log
|
||||
== APP - workflowApp == == APP == Orchestration scheduled with ID: 0c332155-1e02-453a-a333-28cfc7777642
|
||||
== APP - workflowApp == == APP == Waiting 30 seconds for instance 0c332155-1e02-453a-a333-28cfc7777642 to complete...
|
||||
== APP - workflowApp == == APP == Received "Orchestrator Request" work item with instance id '0c332155-1e02-453a-a333-28cfc7777642'
|
||||
|
|
@ -393,7 +394,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -410,9 +411,10 @@ When you ran `dapr run -f .`:
|
|||
1. The `notifyActivity` workflow activity sends a notification saying that order `0c332155-1e02-453a-a333-28cfc7777642` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/workflowApp.ts`
|
||||
#### `order-processor/workflowApp.ts`
|
||||
|
||||
In the application file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -489,12 +491,12 @@ start().catch((e) => {
|
|||
{{% codetab %}}
|
||||
|
||||
The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
|
@ -513,10 +515,10 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic
|
|||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
In a new terminal window, navigate to the `order-processor` directory:
|
||||
In a new terminal window, navigate to the `sdk` directory:
|
||||
|
||||
```bash
|
||||
cd workflows/csharp/sdk/order-processor
|
||||
cd workflows/csharp/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the order processor app
|
||||
|
|
@ -527,7 +529,7 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M
|
|||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -567,7 +569,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -584,9 +586,10 @@ When you ran `dapr run -f .`:
|
|||
1. The `NotifyActivity` workflow activity sends a notification saying that order `6d2abcc9` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/Program.cs`
|
||||
#### `order-processor/Program.cs`
|
||||
|
||||
In the application's program file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -717,6 +720,7 @@ class OrderProcessingWorkflow : Workflow<OrderPayload, OrderResult>
|
|||
#### `order-processor/Activities` directory
|
||||
|
||||
The `Activities` directory holds the four workflow activities used by the workflow, defined in the following files:
|
||||
|
||||
- `NotifyActivity.cs`
|
||||
- `ReserveInventoryActivity.cs`
|
||||
- `ProcessPaymentActivity.cs`
|
||||
|
|
@ -734,22 +738,22 @@ Watch [this video to walk through the Dapr Workflow .NET demo](https://youtu.be/
|
|||
{{% codetab %}}
|
||||
|
||||
The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||
- `RequestApprovalActivity`: Requests approval for processing payment
|
||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
||||
- [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started).
|
||||
- Java JDK 11 (or greater):
|
||||
- [Microsoft JDK 11](https://docs.microsoft.com/java/openjdk/download#openjdk-11)
|
||||
- [Oracle JDK 11](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK11)
|
||||
- [OpenJDK 11](https://jdk.java.net/11/)
|
||||
- [Microsoft JDK 11](https://docs.microsoft.com/java/openjdk/download#openjdk-11)
|
||||
- [Oracle JDK 11](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK11)
|
||||
- [OpenJDK 11](https://jdk.java.net/11/)
|
||||
- [Apache Maven](https://maven.apache.org/install.html) version 3.x.
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
|
|
@ -780,10 +784,11 @@ mvn clean install
|
|||
In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}):
|
||||
|
||||
```bash
|
||||
cd workflows/java/sdk
|
||||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -826,7 +831,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -1073,7 +1078,6 @@ The `Activities` directory holds the four workflow activities used by the workfl
|
|||
<!-- Go -->
|
||||
{{% codetab %}}
|
||||
|
||||
|
||||
The `order-processor` console app starts and manages the `OrderProcessingWorkflow` workflow, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks:
|
||||
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when:
|
||||
|
|
@ -1102,10 +1106,10 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic
|
|||
git clone https://github.com/dapr/quickstarts.git
|
||||
```
|
||||
|
||||
In a new terminal window, navigate to the `order-processor` directory:
|
||||
In a new terminal window, navigate to the `sdk` directory:
|
||||
|
||||
```bash
|
||||
cd workflows/go/sdk/order-processor
|
||||
cd workflows/go/sdk
|
||||
```
|
||||
|
||||
### Step 3: Run the order processor app
|
||||
|
|
@ -1116,7 +1120,7 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M
|
|||
dapr run -f .
|
||||
```
|
||||
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
This starts the `order-processor` app with unique workflow ID and runs the workflow activities.
|
||||
|
||||
Expected output:
|
||||
|
||||
|
|
@ -1157,7 +1161,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -1174,9 +1178,10 @@ When you ran `dapr run`:
|
|||
1. The `NotifyActivity` workflow activity sends a notification saying that order `48ee83b7-5d80-48d5-97f9-6b372f5480a5` has completed.
|
||||
1. The workflow terminates as completed.
|
||||
|
||||
#### `order-processor/main.go`
|
||||
#### `order-processor/main.go`
|
||||
|
||||
In the application's program file:
|
||||
|
||||
- The unique workflow order ID is generated
|
||||
- The workflow is scheduled
|
||||
- The workflow status is retrieved
|
||||
|
|
@ -1317,6 +1322,7 @@ Meanwhile, the `OrderProcessingWorkflow` and its activities are defined as metho
|
|||
{{< /tabs >}}
|
||||
|
||||
## Tell us what you think!
|
||||
|
||||
We're continuously working to improve our Quickstart examples and value your feedback. Did you find this Quickstart helpful? Do you have suggestions for improvement?
|
||||
|
||||
Join the discussion in our [discord channel](https://discord.com/channels/778680217417809931/953427615916638238).
|
||||
|
|
|
|||
|
|
@ -282,4 +282,4 @@ Using regular expressions to reduce metrics cardinality is considered legacy. We
|
|||
## References
|
||||
|
||||
* [Howto: Run Prometheus locally]({{< ref prometheus.md >}})
|
||||
* [Howto: Set up Prometheus and Grafana for metrics]({{< ref grafana.md >}})
|
||||
* [Howto: Set up Prometheus and Grafana for metrics]({{< ref grafana.md >}})
|
||||
|
|
@ -45,6 +45,7 @@ The table below shows the versions of Dapr releases that have been tested togeth
|
|||
|
||||
| Release date | Runtime | CLI | SDKs | Dashboard | Status | Release notes |
|
||||
|--------------------|:--------:|:--------|---------|---------|---------|------------|
|
||||
| June 28th 2024 | 1.13.5</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.5 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.5) |
|
||||
| May 29th 2024 | 1.13.4</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.4 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.4) |
|
||||
| May 21st 2024 | 1.13.3</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.3) |
|
||||
| April 3rd 2024 | 1.13.2</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.2) |
|
||||
|
|
@ -137,9 +138,7 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h
|
|||
| 1.10.0 | N/A | 1.10.8 |
|
||||
| 1.11.0 | N/A | 1.11.4 |
|
||||
| 1.12.0 | N/A | 1.12.4 |
|
||||
| 1.13.0 | N/A | 1.13.2 |
|
||||
| 1.13.0 | N/A | 1.13.3 |
|
||||
| 1.13.0 | N/A | 1.13.4 |
|
||||
| 1.13.0 | N/A | 1.13.5 |
|
||||
|
||||
## Upgrade on Hosting platforms
|
||||
|
||||
|
|
|
|||
|
|
@ -181,6 +181,23 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to
|
|||
|
||||
Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues.
|
||||
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Your queue must have the same name as the topic you are publishing to with Dapr. For example, if you are publishing to the pub/sub `"myPubsub"` on the topic `"orders"`, your queue must be named `"orders"`.
|
||||
If you are using a shared access policy to connect to the queue, that policy must be able to "manage" the queue. To work with a dead-letter queue, the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue.
|
||||
{{% /alert %}}
|
||||
|
||||
### Retry policy and dead-letter queues
|
||||
|
||||
By default, an Azure Service Bus Queue has a dead-letter queue. The messages are retried the amount given for `maxDeliveryCount`. The default `maxDeliveryCount` value defaults to 10, but can be set up to 2000. These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned.
|
||||
|
||||
Dapr Pub/sub offers its own dead-letter queue concept that lets you control the retry policy and subscribe to the dead-letter queue through Dapr.
|
||||
1. Set up a separate queue as that dead-letter queue in the Azure Service Bus namespace, and a resilience policy that defines how to retry.
|
||||
1. Subscribe to the topic to get the failed messages and deal with them.
|
||||
|
||||
For example, setting up a dead-letter queue `orders-dlq` in the subscription and a resiliency policy lets you subscribe to the topic `orders-dlq` to handle failed messages.
|
||||
|
||||
For more details on setting up dead-letter queues, see the [dead-letter article]({{< ref pubsub-deadletter >}}).
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{< ref component-schema >}})
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.0{{ else }}1.13.4{{ end -}}
|
||||
{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.5{{ else if .Get "cli" }}1.13.0{{ else }}1.13.5{{ end -}}
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Subproject commit c07eb698ac5d1b152a60d76c64af4841ffa07397
|
||||
Subproject commit 56367963f46257fbcb109f671ac78dc445435012
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 5ef7aa2234d4d4c07769ad31cde223ef11c4e33e
|
||||
Subproject commit 7c03c7ce58d100a559ac1881bc0c80d6dedc5ab9
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 2f5947392a33bc7911e6669601ddb9e8b59b58fe
|
||||
Subproject commit a98327e7d9a81611b0d7e91e59ea23ad48271948
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 4189a3d2ad6897406abd766f4ccbf2300c8f8852
|
||||
Subproject commit 7350742b6869cc166633d1f4d17d76fbdbb12921
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 0b7aafdab1d4fade424b1b6c9569329ad10bb516
|
||||
Subproject commit 64a4f2f6658e9023e8ea080eefdb019645cae802
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit ed283c2e259c21cc77a24b3dbc03733103455f1b
|
||||
Subproject commit 4abf5aa6504f7c0b0018d20f8dc038a486a67e3a
|
||||
Loading…
Reference in New Issue