diff --git a/charts/argo-workflows/Chart.yaml b/charts/argo-workflows/Chart.yaml index 025d1f5a..df7abbc4 100644 --- a/charts/argo-workflows/Chart.yaml +++ b/charts/argo-workflows/Chart.yaml @@ -2,7 +2,7 @@ apiVersion: v2 name: argo-workflows description: A Helm chart for Argo Workflows type: application -version: 0.14.1 +version: 0.14.2 appVersion: v3.3.2 icon: https://raw.githubusercontent.com/argoproj/argo-workflows/master/docs/assets/argo.png home: https://github.com/argoproj/argo-helm @@ -15,4 +15,4 @@ maintainers: - name: benjaminws annotations: artifacthub.io/changes: | - - "[Fixed]: Add missing create verb to workflowtaskresults for the workflow role" + - "[Fixed]: Fix typos and add missing words in README" diff --git a/charts/argo-workflows/README.md b/charts/argo-workflows/README.md index 02e420eb..ac032034 100644 --- a/charts/argo-workflows/README.md +++ b/charts/argo-workflows/README.md @@ -1,23 +1,23 @@ # Argo Workflows Chart -This is a **community maintained** chart. It is used to set up argo and it's needed dependencies through one command. This is used in conjunction with [helm](https://github.com/kubernetes/helm). +This is a **community maintained** chart. It is used to set up argo and its needed dependencies through one command. This is used in conjunction with [helm](https://github.com/kubernetes/helm). If you want your deployment of this helm chart to most closely match the [argo CLI](https://github.com/argoproj/argo-workflows), you should deploy it in the `kube-system` namespace. ## Pre-Requisites -This chart uses an install hook to configure the CRD definition. Installation of CRDs is a somewhat privileged process in itself and in RBAC enabled clusters the `default` service account for namespaces does not typically have the ability to do create these. +This chart uses an install hook to configure the CRD definition. Installation of CRDs is a somewhat privileged process in itself and in RBAC enabled clusters the `default` service account for namespaces does not typically have the ability to create these. A few options are: -- Manually create a ServiceAccount in the Namespace which your release will be deployed w/ appropriate bindings to perform this action and set the `serviceAccountName` field in the Workflow spec +- Manually create a ServiceAccount in the Namespace in which your release will be deployed w/ appropriate bindings to perform this action and set the `serviceAccountName` field in the Workflow spec - Augment the `default` ServiceAccount permissions in the Namespace in which your Release is deployed to have the appropriate permissions ## Usage Notes ### Workflow controller -This chart defaults to setting the `controller.instanceID.enabled` to `false` now, which means the deployed controller will act upon any workflow deployed to the cluster. If you would like to limit the behavior and deploy multiple workflow controllers, please use the `controller.instanceID.enabled` attribute along with one of it's configuration options to set the `instanceID` of the workflow controller to be properly scoped for your needs. +This chart defaults to setting the `controller.instanceID.enabled` to `false` now, which means the deployed controller will act upon any workflow deployed to the cluster. If you would like to limit the behavior and deploy multiple workflow controllers, please use the `controller.instanceID.enabled` attribute along with one of its configuration options to set the `instanceID` of the workflow controller to be properly scoped for your needs. ### Workflow server authentication @@ -217,7 +217,7 @@ Fields to note: 1. switched to quay.io as the default registry for all images 1. removed any included usage of Minio 1. aligned the configuration of serviceAccounts with the argo-cd chart, ie: what used to be `server.createServiceAccount` is now `server.serviceAccount.create` -1. moved the previously known as `telemetryServicePort` inside the `telemetryConfig` as `telemetryConfig.servicePort` - same for `metricsConfig` +1. moved the field previously known as `telemetryServicePort` inside the `telemetryConfig` as `telemetryConfig.servicePort` - same for `metricsConfig` [affinity]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ [links]: https://argoproj.github.io/argo-workflows/links/ diff --git a/charts/argo-workflows/README.md.gotmpl b/charts/argo-workflows/README.md.gotmpl index 3f9a0121..4f5fe410 100644 --- a/charts/argo-workflows/README.md.gotmpl +++ b/charts/argo-workflows/README.md.gotmpl @@ -1,23 +1,23 @@ # Argo Workflows Chart -This is a **community maintained** chart. It is used to set up argo and it's needed dependencies through one command. This is used in conjunction with [helm](https://github.com/kubernetes/helm). +This is a **community maintained** chart. It is used to set up argo and its needed dependencies through one command. This is used in conjunction with [helm](https://github.com/kubernetes/helm). If you want your deployment of this helm chart to most closely match the [argo CLI](https://github.com/argoproj/argo-workflows), you should deploy it in the `kube-system` namespace. ## Pre-Requisites -This chart uses an install hook to configure the CRD definition. Installation of CRDs is a somewhat privileged process in itself and in RBAC enabled clusters the `default` service account for namespaces does not typically have the ability to do create these. +This chart uses an install hook to configure the CRD definition. Installation of CRDs is a somewhat privileged process in itself and in RBAC enabled clusters the `default` service account for namespaces does not typically have the ability to create these. A few options are: -- Manually create a ServiceAccount in the Namespace which your release will be deployed w/ appropriate bindings to perform this action and set the `serviceAccountName` field in the Workflow spec +- Manually create a ServiceAccount in the Namespace in which your release will be deployed w/ appropriate bindings to perform this action and set the `serviceAccountName` field in the Workflow spec - Augment the `default` ServiceAccount permissions in the Namespace in which your Release is deployed to have the appropriate permissions ## Usage Notes ### Workflow controller -This chart defaults to setting the `controller.instanceID.enabled` to `false` now, which means the deployed controller will act upon any workflow deployed to the cluster. If you would like to limit the behavior and deploy multiple workflow controllers, please use the `controller.instanceID.enabled` attribute along with one of it's configuration options to set the `instanceID` of the workflow controller to be properly scoped for your needs. +This chart defaults to setting the `controller.instanceID.enabled` to `false` now, which means the deployed controller will act upon any workflow deployed to the cluster. If you would like to limit the behavior and deploy multiple workflow controllers, please use the `controller.instanceID.enabled` attribute along with one of its configuration options to set the `instanceID` of the workflow controller to be properly scoped for your needs. ### Workflow server authentication @@ -115,7 +115,7 @@ Fields to note: 1. switched to quay.io as the default registry for all images 1. removed any included usage of Minio 1. aligned the configuration of serviceAccounts with the argo-cd chart, ie: what used to be `server.createServiceAccount` is now `server.serviceAccount.create` -1. moved the previously known as `telemetryServicePort` inside the `telemetryConfig` as `telemetryConfig.servicePort` - same for `metricsConfig` +1. moved the field previously known as `telemetryServicePort` inside the `telemetryConfig` as `telemetryConfig.servicePort` - same for `metricsConfig` [affinity]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ [links]: https://argoproj.github.io/argo-workflows/links/