[DATALAD RUNCMD] run codespell throughout but ignore fail

=== Do not change lines below === { "chain": [], "cmd": "codespell -w || :", "exit": 0, "extra_inputs": [], "inputs": [], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^ Signed-off-by: Yaroslav Halchenko <[email protected]>
flyteorg · Sep 20, 2023 · 783f796 · 783f796
1 parent e609875
commit 783f796
Show file tree

Hide file tree

Showing 115 changed files with 194 additions and 194 deletions.
diff --git a/CHANGELOG/CHANGELOG-v0.18.2.md b/CHANGELOG/CHANGELOG-v0.18.2.md
@@ -29,7 +29,7 @@ See the flytekit [0.25.0 release notes](https://github.com/flyteorg/flytekit/rel
   In addition to component-specific versions released from each of the flyte repositories (e.g. flytepropeller:v0.16.5), new images will be re-tagged and pushed that match the flyte release version (e.g. the upcoming flytepropeller-release:v0.18.2). This makes it easier to make sure all your deployments are on the same version to ensure best compatibility.
 * Helm changes
     * [flyte-core](https://artifacthub.io/packages/helm/flyte/flyte-core) helm chart has reached release preview and can be leveraged to install your cloud(AWS/GCP) deployments of flyte.
-    * Going forward flyte-core will install flyte native scheduler, For AWS backword compatibility you need to define `workflow_schedule.type` to `aws`. (https://github.com/flyteorg/flyte/pull/1896)
+    * Going forward flyte-core will install flyte native scheduler, For AWS backward compatibility you need to define `workflow_schedule.type` to `aws`. (https://github.com/flyteorg/flyte/pull/1896)
     * [flyte](https://artifacthub.io/packages/helm/flyte/flyte) helm chart has been refactored to depend on flyte-core helm chart and install additional dependencies to continue to provide a sandboxed installation of flyte.
 
     **Migration Notes**
@@ -59,4 +59,4 @@ See the flytekit [0.25.0 release notes](https://github.com/flyteorg/flytekit/rel
       countour:
         ...    
       ```
-    * Alternatively, if you do not have any dependency on external flyte depdencies, you can keep your ``myvalues.yaml`` and switch to using ``flyte-core`` helm chart directly with no changes.
+    * Alternatively, if you do not have any dependency on external flyte dependencies, you can keep your ``myvalues.yaml`` and switch to using ``flyte-core`` helm chart directly with no changes.
diff --git a/CHANGELOG/CHANGELOG-v0.7.0.md b/CHANGELOG/CHANGELOG-v0.7.0.md
@@ -9,7 +9,7 @@
 - Large steps towards intracloud workflow portability
 
 ## Console
- - Ability to track lineage and caching information directly in the UI. On a cache hit - possible to jump to the orginating execution.
+ - Ability to track lineage and caching information directly in the UI. On a cache hit - possible to jump to the originating execution.
  - Ability to clone an execution
  - bug fixes
 

diff --git a/CHANGELOG/CHANGELOG-v1.2.0.md b/CHANGELOG/CHANGELOG-v1.2.0.md
@@ -4,7 +4,7 @@
 - Support for Ray (https://github.com/flyteorg/flyte/issues/2641) - Also see the [blog post](https://blog.flyte.org/ray-and-flyte). 
 - Execution names can be longer now, up to 63 characters (https://github.com/flyteorg/flyteadmin/pull/466)
 - Offloading FlyteWorkflow CRD static workflow spec (https://github.com/flyteorg/flyte/issues/2705)
-- Enabled FlytePropeller subqueue - this means that everytime a pod is updated in the workflow it reevals for faster downstream scheduling
+- Enabled FlytePropeller subqueue - this means that every time a pod is updated in the workflow it reevals for faster downstream scheduling
 - Add container configuration to default pod template (https://github.com/flyteorg/flyte/issues/2703)
 - Fixed issues with blobstore writes - GCS had duplicate writes and subworkflow inputs were rewritten on every evaluation, this meant slower evaluations
 - Support external deletion of non-terminal map task subtasks (as a result of https://github.com/flyteorg/flyte/issues/2701)

diff --git a/CHANGELOG/CHANGELOG-v1.3.0.md b/CHANGELOG/CHANGELOG-v1.3.0.md
@@ -95,7 +95,7 @@ r.set_signal("signal-name", "execidabc123", True)
 ```
 
 ### Overwritten Cached Values on Execution
-Users can now configure workflow execution to overwrite the cache. Each task in the workflow execution, regardless of previous cache status, will execute and write cached values - overwritting previous values if necessary. This allows previously corrupted cache values to be corrected without the tedious process of incrementing the `cache_version` and re-registering Flyte workflows / tasks.
+Users can now configure workflow execution to overwrite the cache. Each task in the workflow execution, regardless of previous cache status, will execute and write cached values - overwriting previous values if necessary. This allows previously corrupted cache values to be corrected without the tedious process of incrementing the `cache_version` and re-registering Flyte workflows / tasks.
 
 
 ### Support for Dask

diff --git a/CHANGELOG/CHANGELOG-v1.4.0.md b/CHANGELOG/CHANGELOG-v1.4.0.md
@@ -1,7 +1,7 @@
 # Flyte 1.4 release
 
 The main features of the 1.4 release are:
-- Suport for `PodTemplate` at the task-level
+- Support for `PodTemplate` at the task-level
 - Revamped auth system in flytekit
 
 As python 3.7 [reached](https://endoflife.date/python) EOL support in December of 2022, we dropped support for that version on this release.
@@ -58,7 +58,7 @@ In https://github.com/flyteorg/flytekit/pull/1458 we introduced a new OAuth2 han
 ## New sandbox features
 In this new release `flytectl demo` brings the following new features:
 - Support for specifying extra configuration for Flyte
-- Support for specifying extra cluster resource templates for boostrapping new namespaces
+- Support for specifying extra cluster resource templates for bootstrapping new namespaces
 - Sandbox state (DB, buckets) is now persistent across restarts and upgrades
 
 ## Flyteconsole

diff --git a/boilerplate/flyte/golang_test_targets/go-gen.sh b/boilerplate/flyte/golang_test_targets/go-gen.sh
@@ -9,7 +9,7 @@ go generate ./...
 if [ -n "$DELTA_CHECK" ]; then
   DIRTY=$(git status --porcelain)
   if [ -n "$DIRTY" ]; then
-    echo "FAILED: Go code updated without commiting generated code."
+    echo "FAILED: Go code updated without committing generated code."
     echo "Ensure make generate has run and all changes are committed."
     DIFF=$(git diff)
     echo "diff detected: $DIFF"

diff --git a/charts/flyte-binary/values.yaml b/charts/flyte-binary/values.yaml
@@ -116,7 +116,7 @@ configuration:
       clientSecret: ""
     # internal Configuration for internal authentication
     # The settings for internal still need to be defined if you wish to use an external auth server
-    # These credentials are used during communication beteween the FlyteAdmin and Propeller microservices
+    # These credentials are used during communication between the FlyteAdmin and Propeller microservices
     internal:
       # clientId Client ID for internal authentication - set to flytepropeller or external auth server
       clientId: flytepropeller

diff --git a/charts/flyte-core/README.md b/charts/flyte-core/README.md
@@ -48,7 +48,7 @@ helm install gateway bitnami/contour -n flyte
 
 ### CONFIGURATION NOTES:
 - The docker images, their tags and other default parameters are configured in `values.yaml` file.
-- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the choosen config `values-*.yaml` are merged when generating the deployment manifest.
+- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the chosen config `values-*.yaml` are merged when generating the deployment manifest.
 - The configuration in `values-sandbox.yaml` is ready for installation in minikube. But `values-eks.yaml` should be edited before installation: s3 bucket, RDS hosts, iam roles, secrets and etc need to be modified.
 
 ## Values

diff --git a/charts/flyte-core/README.md.gotmpl b/charts/flyte-core/README.md.gotmpl
@@ -52,7 +52,7 @@ helm install gateway bitnami/contour -n flyte
 
 ### CONFIGURATION NOTES:
 - The docker images, their tags and other default parameters are configured in `values.yaml` file.
-- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the choosen config `values-*.yaml` are merged when generating the deployment manifest.
+- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the chosen config `values-*.yaml` are merged when generating the deployment manifest.
 - The configuration in `values-sandbox.yaml` is ready for installation in minikube. But `values-eks.yaml` should be edited before installation: s3 bucket, RDS hosts, iam roles, secrets and etc need to be modified.
 
 {{ template "chart.valuesSection" . }}
diff --git a/charts/flyte-core/values-eks-override.yaml b/charts/flyte-core/values-eks-override.yaml
@@ -1,6 +1,6 @@
 # -- # Flyte uses a cloud hosted Cron scheduler to run workflows on a schedule. The following module is optional. Without,
 # this module, you will not have scheduled launchplans/workflows.
-# we support native scheduler and this is for backward compatability to older scheduler only
+# we support native scheduler and this is for backward compatibility to older scheduler only
 workflow_scheduler:
   enabled: true
   type: aws

diff --git a/charts/flyte-deps/README.md b/charts/flyte-deps/README.md
@@ -44,7 +44,7 @@ helm upgrade -f values.yaml flyte .
 
 ### CONFIGURATION NOTES:
 - The docker images, their tags and other default parameters are configured in `values.yaml` file.
-- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the choosen config `values-*.yaml` are merged when generating the deployment manifest.
+- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the chosen config `values-*.yaml` are merged when generating the deployment manifest.
 
 ## Values
 

diff --git a/charts/flyte-deps/README.md.gotmpl b/charts/flyte-deps/README.md.gotmpl
@@ -45,6 +45,6 @@ helm upgrade -f values.yaml flyte .
 
 ### CONFIGURATION NOTES:
 - The docker images, their tags and other default parameters are configured in `values.yaml` file.
-- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the choosen config `values-*.yaml` are merged when generating the deployment manifest.
+- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the chosen config `values-*.yaml` are merged when generating the deployment manifest.
 
 {{ template "chart.valuesSection" . }}
diff --git a/charts/flyte/README.md b/charts/flyte/README.md
@@ -14,7 +14,7 @@ A Helm chart for Flyte Sandbox
 | https://helm.dask.org | daskoperator(dask-kubernetes-operator) | 2022.12.0 |
 | https://kubernetes.github.io/dashboard/ | kubernetes-dashboard | 4.0.2 |
 
-**NOTE:** Flyte sandbox helm chart is depricated, From now follow the sandbox [docs](https://docs.flyte.org/en/latest/deployment/sandbox.html) for installing it on cloud
+**NOTE:** Flyte sandbox helm chart is deprecated, From now follow the sandbox [docs](https://docs.flyte.org/en/latest/deployment/sandbox.html) for installing it on cloud
 
 ### SANDBOX INSTALLATION:
 - [Install helm 3](https://helm.sh/docs/intro/install/)
@@ -47,7 +47,7 @@ helm upgrade -f values-sandbox.yaml flyte .
 
 ### CONFIGURATION NOTES:
 - The docker images, their tags and other default parameters are configured in `values.yaml` file.
-- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the choosen config `values-*.yaml` are merged when generating the deployment manifest.
+- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the chosen config `values-*.yaml` are merged when generating the deployment manifest.
 
 ## Values
 

diff --git a/charts/flyte/README.md.gotmpl b/charts/flyte/README.md.gotmpl
@@ -13,7 +13,7 @@
 
 {{ template "chart.requirementsSection" . }}
 
-**NOTE:** Flyte sandbox helm chart is depricated, From now follow the sandbox [docs](https://docs.flyte.org/en/latest/deployment/sandbox.html) for installing it on cloud
+**NOTE:** Flyte sandbox helm chart is deprecated, From now follow the sandbox [docs](https://docs.flyte.org/en/latest/deployment/sandbox.html) for installing it on cloud
 
 ### SANDBOX INSTALLATION:
 - [Install helm 3](https://helm.sh/docs/intro/install/)
@@ -47,6 +47,6 @@ helm upgrade -f values-sandbox.yaml flyte .
 
 ### CONFIGURATION NOTES:
 - The docker images, their tags and other default parameters are configured in `values.yaml` file.
-- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the choosen config `values-*.yaml` are merged when generating the deployment manifest.
+- Each Flyte installation type should have separate `values-*.yaml` file: for sandbox, EKS and etc. The configuration in `values.yaml` and the chosen config `values-*.yaml` are merged when generating the deployment manifest.
 
 {{ template "chart.valuesSection" . }}
diff --git a/datacatalog/boilerplate/flyte/docker_build/docker_build.sh b/datacatalog/boilerplate/flyte/docker_build/docker_build.sh
@@ -43,7 +43,7 @@ fi
 docker build -t "$IMAGE_TAG_WITH_SHA" --target=${BUILD_PHASE} .
 echo "${IMAGE_TAG_WITH_SHA} built locally."
 
-# if REGISTRY specified, push the images to the remote registy
+# if REGISTRY specified, push the images to the remote registry
 if [ -n "$REGISTRY" ]; then
 
   if [ -n "${DOCKER_REGISTRY_PASSWORD}" ]; then

diff --git a/datacatalog/boilerplate/flyte/github_workflows/Readme.rst b/datacatalog/boilerplate/flyte/github_workflows/Readme.rst
@@ -7,7 +7,7 @@ Provides a two github actions workflows.
 
 Add ``flyteorg/github_workflows`` to your ``boilerplate/update.cfg`` file.
 
-Add a github secret ``package_name`` with the name to use for publishing (e.g. ``flytepropeller``). Typicaly, this will be the same name as the repository.
+Add a github secret ``package_name`` with the name to use for publishing (e.g. ``flytepropeller``). Typically, this will be the same name as the repository.
 
 *Note*: If you are working on a fork, include that prefix in your package name (``myfork/flytepropeller``).
 
@@ -18,5 +18,5 @@ The actions will push to 2 repos:
 
 There are two workflows that get deployed:
 
-	1. A workflow that runs on Pull Requests to build and push images to github registy tagged with the commit sha.
+	1. A workflow that runs on Pull Requests to build and push images to github registry tagged with the commit sha.
 	2. A workflow that runs on master merges that bump the patch version of release tag, builds and pushes images to github registry tagged with the version, commit sha as well as "latest"
diff --git a/datacatalog/boilerplate/flyte/golang_test_targets/go-gen.sh b/datacatalog/boilerplate/flyte/golang_test_targets/go-gen.sh
@@ -9,7 +9,7 @@ go generate ./...
 if [ -n "$DELTA_CHECK" ]; then
   DIRTY=$(git status --porcelain)
   if [ -n "$DIRTY" ]; then
-    echo "FAILED: Go code updated without commiting generated code."
+    echo "FAILED: Go code updated without committing generated code."
     echo "Ensure make generate has run and all changes are committed."
     DIFF=$(git diff)
     echo "diff detected: $DIFF"

diff --git a/datacatalog/pkg/rpc/datacatalogservice/service.go b/datacatalog/pkg/rpc/datacatalogservice/service.go
@@ -81,7 +81,7 @@ func NewDataCatalogService() *DataCatalogService {
 	defer func() {
 		if err := recover(); err != nil {
 			catalogScope.MustNewCounter("initialization_panic",
-				"panics encountered initializating the datacatalog service").Inc()
+				"panics encountered initializing the datacatalog service").Inc()
 			logger.Fatalf(context.Background(), fmt.Sprintf("caught panic: %v [%+v]", err, string(debug.Stack())))
 		}
 	}()

diff --git a/flyteadmin/boilerplate/flyte/docker_build/docker_build.sh b/flyteadmin/boilerplate/flyte/docker_build/docker_build.sh
@@ -43,7 +43,7 @@ fi
 docker build -t "$IMAGE_TAG_WITH_SHA" --target=${BUILD_PHASE} .
 echo "${IMAGE_TAG_WITH_SHA} built locally."
 
-# if REGISTRY specified, push the images to the remote registy
+# if REGISTRY specified, push the images to the remote registry
 if [ -n "$REGISTRY" ]; then
 
   if [ -n "${DOCKER_REGISTRY_PASSWORD}" ]; then

diff --git a/flyteadmin/boilerplate/flyte/github_workflows/Readme.rst b/flyteadmin/boilerplate/flyte/github_workflows/Readme.rst
@@ -7,7 +7,7 @@ Provides a two github actions workflows.
 
 Add ``flyteorg/github_workflows`` to your ``boilerplate/update.cfg`` file.
 
-Add a github secret ``package_name`` with the name to use for publishing (e.g. ``flytepropeller``). Typicaly, this will be the same name as the repository.
+Add a github secret ``package_name`` with the name to use for publishing (e.g. ``flytepropeller``). Typically, this will be the same name as the repository.
 
 *Note*: If you are working on a fork, include that prefix in your package name (``myfork/flytepropeller``).
 
@@ -18,5 +18,5 @@ The actions will push to 2 repos:
 
 There are two workflows that get deployed:
 
-	1. A workflow that runs on Pull Requests to build and push images to github registy tagged with the commit sha.
+	1. A workflow that runs on Pull Requests to build and push images to github registry tagged with the commit sha.
 	2. A workflow that runs on master merges that bump the patch version of release tag, builds and pushes images to github registry tagged with the version, commit sha as well as "latest"
diff --git a/flyteadmin/boilerplate/flyte/golang_test_targets/go-gen.sh b/flyteadmin/boilerplate/flyte/golang_test_targets/go-gen.sh
@@ -9,7 +9,7 @@ go generate ./...
 if [ -n "$DELTA_CHECK" ]; then
   DIRTY=$(git status --porcelain)
   if [ -n "$DIRTY" ]; then
-    echo "FAILED: Go code updated without commiting generated code."
+    echo "FAILED: Go code updated without committing generated code."
     echo "Ensure make generate has run and all changes are committed."
     DIFF=$(git diff)
     echo "diff detected: $DIFF"

diff --git a/flyteadmin/pkg/common/filters.go b/flyteadmin/pkg/common/filters.go
@@ -241,7 +241,7 @@ func customizeField(field string, entity Entity) string {
 }
 
 func customizeEntity(field string, entity Entity) Entity {
-	// NamedEntity is considered a single object, but the metdata
+	// NamedEntity is considered a single object, but the metadata
 	// is stored using a different entity type.
 	if entity == NamedEntity && entityMetadataFields[field] {
 		return NamedEntityMetadata

diff --git a/flyteadmin/pkg/common/flyte_url.go b/flyteadmin/pkg/common/flyte_url.go
@@ -14,7 +14,7 @@ import (
 
 type ArtifactType int
 
-// The suffixes in these constants are used to match against the tail end of the flyte url, to keep tne flyte url simpler
+// The suffixes in these constants are used to match against the tail end of the flyte url, to keep the flyte url simpler
 const (
 	ArtifactTypeUndefined ArtifactType = iota
 	ArtifactTypeI                      // inputs

diff --git a/flyteadmin/pkg/manager/impl/validation/task_validator.go b/flyteadmin/pkg/manager/impl/validation/task_validator.go
@@ -293,7 +293,7 @@ func validateTaskType(taskID core.Identifier, taskType string, whitelistConfig r
 		} else if scope.Project != taskID.Project {
 			continue
 		}
-		// We have a potential match! Verify that this task type is approved given the specifity of the whitelist.
+		// We have a potential match! Verify that this task type is approved given the specificity of the whitelist.
 		if scope.Domain == "" {
 			// All domains for this project are whitelisted
 			return nil

diff --git a/flyteadmin/scheduler/core/gocron_scheduler.go b/flyteadmin/scheduler/core/gocron_scheduler.go
@@ -122,7 +122,7 @@ func (g *GoCronScheduler) ScheduleJob(ctx context.Context, schedule models.Sched
 
 	// Update the catchupFrom time as the lastExecTime.
 	// Here lastExecTime is passed to this function only from BootStrapSchedulesFromSnapShot which is during bootup
-	// Once initialized we wont be changing the catchupTime until the next boot
+	// Once initialized we won't be changing the catchupTime until the next boot
 	job := &GoCronJob{nameOfSchedule: nameOfSchedule, schedule: schedule, funcWithSchedule: funcWithSchedule,
 		catchupFromTime: lastExecTime, lastExecTime: lastExecTime, ctx: ctx}
 
@@ -276,7 +276,7 @@ func (g *GoCronScheduler) AddFixedIntervalJob(ctx context.Context, job *GoCronJo
 		lastTime = *job.lastExecTime
 	}
 	entryID := g.cron.ScheduleTimedJob(cron.ConstantDelaySchedule{Delay: d}, jobFunc, lastTime)
-	// Update the enttry id in the job which is handle to be used for removal
+	// Update the entry id in the job which is handle to be used for removal
 	job.entryID = entryID
 	logger.Infof(ctx, "successfully added the fixed rate schedule %s to the scheduler for schedule %+v",
 		job.nameOfSchedule, job.schedule)
@@ -298,7 +298,7 @@ func (g *GoCronScheduler) AddCronJob(ctx context.Context, job *GoCronJob) error
 	jobFunc = job.Run
 
 	entryID, err := g.cron.AddTimedJob(job.schedule.CronExpression, jobFunc)
-	// Update the enttry id in the job which is handle to be used for removal
+	// Update the entry id in the job which is handle to be used for removal
 	job.entryID = entryID
 	if err == nil {
 		logger.Infof(ctx, "successfully added the schedule %s to the scheduler for schedule %+v",

diff --git a/flyteadmin/scheduler/doc.go b/flyteadmin/scheduler/doc.go
@@ -74,7 +74,7 @@
 //		    During the discrepancy the executions won't be scheduled on admin once the bug(1354) is fixed.
 //
 //      b) Case when scheduled time T1 execution fails. The goroutine executing for T1 will go through 30 repetitions before
-//		   aborting the run. In such a scenario its possible that furture scheduled time T2 succeeds and gets executed successfully
+//		   aborting the run. In such a scenario its possible that future scheduled time T2 succeeds and gets executed successfully
 //		   by the admin. i.e admin could execute the schedules in this order T2, T1. This is rare case though
 //
 // 		c) Case when the scheduler goes down then once it comes back up it will run catch up on all the schedules using

diff --git a/flyteadmin/scheduler/repositories/gormimpl/schedule_entities_snapshot_repo.go b/flyteadmin/scheduler/repositories/gormimpl/schedule_entities_snapshot_repo.go
@@ -18,7 +18,7 @@ type ScheduleEntitiesSnapshotRepo struct {
 	metrics          gormMetrics
 }
 
-// TODO : always overwrite the exisiting snapshot instead of creating new rows
+// TODO : always overwrite the existing snapshot instead of creating new rows
 func (r *ScheduleEntitiesSnapshotRepo) Write(ctx context.Context, input models.ScheduleEntitiesSnapshot) error {
 	timer := r.metrics.GetDuration.Start()
 	tx := r.db.Omit("id").Create(&input)