This is an automated email from the ASF dual-hosted git repository.
vincbeck pushed a commit to branch v3-3-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v3-3-test by this push:
new 9a7a272459d [v3-3-test] Fix typos across contributor and provider
documentation (#71884) (#71903)
9a7a272459d is described below
commit 9a7a272459d959b6f713000a31a2cf9b09f6db67
Author: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
AuthorDate: Thu Aug 20 13:54:54 2026 -0400
[v3-3-test] Fix typos across contributor and provider documentation
(#71884) (#71903)
These misspellings fall outside codespell's dictionary, so the prek hook
never flagged them and they accumulated unnoticed.
One of them misnamed generated/provider_dependencies.json in the CI
workflow docs, sending readers to a path that does not exist.
(cherry picked from commit 089ec0078bf171d57cc7b2bc5bdd5039ba556365)
Co-authored-by: Andrii Roiko <[email protected]>
---
airflow-core/docs/installation/installing-from-sources.rst | 2 +-
contributing-docs/testing/k8s_tests.rst | 2 +-
contributing-docs/testing/system_tests.rst | 2 +-
dev/breeze/doc/08_ci_tasks.rst | 2 +-
dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md | 6 +++---
.../0005-preventing-using-contributed-code-when-building-images.md | 2 +-
dev/breeze/doc/adr/0011-unified-communication-with-the-users.md | 2 +-
dev/breeze/doc/ci/04_selective_checks.md | 2 +-
dev/breeze/doc/ci/05_workflows.md | 2 +-
docker-context-files/.README.md | 2 +-
.../apache/hive/tests/system/apache/hive/example_twitter_README.md | 4 ++--
providers/apache/tinkerpop/docs/connections/tinkerpop.rst | 2 +-
providers/microsoft/azure/docs/connections/azure_batch.rst | 2 +-
shared/README.md | 4 ++--
14 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/airflow-core/docs/installation/installing-from-sources.rst
b/airflow-core/docs/installation/installing-from-sources.rst
index 6bb7f8c34d3..f807fa96ec1 100644
--- a/airflow-core/docs/installation/installing-from-sources.rst
+++ b/airflow-core/docs/installation/installing-from-sources.rst
@@ -44,7 +44,7 @@ The ``|version|`` downloads of Airflow® are available at:
* `Sources package for airflow <{{ closer_lua_url }}/apache_airflow-{{
airflow_version }}-source.tar.gz>`__ (`asc <{{ base_url }}/apache_airflow-{{
airflow_version }}-source.tar.gz.asc>`__, `sha512 <{{ base_url
}}/apache_airflow-{{ airflow_version }}-source.tar.gz.sha512>`__)
* `Sdist package for airflow meta distribution <{{ closer_lua_url
}}/apache_airflow-{{ airflow_version }}.tar.gz>`__ (`asc <{{ base_url
}}/apache_airflow-{{ airflow_version }}.tar.gz.asc>`__, `sha512 <{{ base_url
}}/apache_airflow-{{ airflow_version }}.tar.gz.sha512>`__)
- * `Whl package for airflow meta distributio <{{ closer_lua_url
}}/apache_airflow-{{ airflow_version }}-py3-none-any.whl>`__ (`asc <{{ base_url
}}/apache_airflow-{{ airflow_version }}-py3-none-any.whl.asc>`__, `sha512 <{{
base_url }}/apache_airflow-{{ airflow_version }}-py3-none-any.whl.sha512>`__)
+ * `Whl package for airflow meta distribution <{{ closer_lua_url
}}/apache_airflow-{{ airflow_version }}-py3-none-any.whl>`__ (`asc <{{ base_url
}}/apache_airflow-{{ airflow_version }}-py3-none-any.whl.asc>`__, `sha512 <{{
base_url }}/apache_airflow-{{ airflow_version }}-py3-none-any.whl.sha512>`__)
* `Sdist package for airflow core distribution <{{ closer_lua_url
}}/apache_airflow_core-{{ airflow_version }}.tar.gz>`__ (`asc <{{ base_url
}}/apache_airflow_core-{{ airflow_version }}.tar.gz.asc>`__, `sha512 <{{
base_url }}/apache_airflow_core-{{ airflow_version }}.tar.gz.sha512>`__)
* `Whl package for airflow core distribution <{{ closer_lua_url
}}/apache_airflow_core-{{ airflow_version }}-py3-none-any.whl>`__ (`asc <{{
base_url }}/apache_airflow_core-{{ airflow_version }}-py3-none-any.whl.asc>`__,
`sha512 <{{ base_url }}/apache_airflow_core-{{ airflow_version
}}-py3-none-any.whl.sha512>`__)
* `Sdist package for airflow task-sdk distribution <{{
closer_lua_url_task_sdk }}/apache_airflow_task_sdk-{{ task_sdk_version
}}.tar.gz>`__ (`asc <{{ base_url_task_sdk }}/apache_airflow_task_sdk-{{
task_sdk_version }}.tar.gz.asc>`__, `sha512 <{{ base_url_task_sdk
}}/apache_airflow_task_sdk-{{ task_sdk_version }}.tar.gz.sha512>`__)
diff --git a/contributing-docs/testing/k8s_tests.rst
b/contributing-docs/testing/k8s_tests.rst
index 299e77dfb5b..807ce24e213 100644
--- a/contributing-docs/testing/k8s_tests.rst
+++ b/contributing-docs/testing/k8s_tests.rst
@@ -672,7 +672,7 @@ Airflow to KinD cluster.
10. Dumping logs
-Sometimes You want to see the logs of the clister. This can be done with
``breeze k8s logs``.
+Sometimes You want to see the logs of the cluster. This can be done with
``breeze k8s logs``.
.. code-block:: bash
diff --git a/contributing-docs/testing/system_tests.rst
b/contributing-docs/testing/system_tests.rst
index 16709663e45..46ef87ed202 100644
--- a/contributing-docs/testing/system_tests.rst
+++ b/contributing-docs/testing/system_tests.rst
@@ -177,7 +177,7 @@ Running manually via Pytest outside of the Airflow codebase
2. Airflow API server
- In case you want to run tests agasint an Airflow Executor, you will need to
have the Airflow API server available.
+ In case you want to run tests against an Airflow Executor, you will need to
have the Airflow API server available.
NOTE: You have to make sure that the API server is sharing certain
configuration as the test environment. This is
particularly important so that the Airflow Task SDK may be able to
communicate to the API Server.
diff --git a/dev/breeze/doc/08_ci_tasks.rst b/dev/breeze/doc/08_ci_tasks.rst
index 7165a598756..747491107fe 100644
--- a/dev/breeze/doc/08_ci_tasks.rst
+++ b/dev/breeze/doc/08_ci_tasks.rst
@@ -18,7 +18,7 @@
CI tasks
========
-Breeze hase a number of commands that are mostly used in CI environment to
perform cleanup.
+Breeze has a number of commands that are mostly used in CI environment to
perform cleanup.
Detailed description of the CI design can be found in `CI design
<ci/README.md>`_.
**The outline for this document in GitHub is available at top-right corner
button (with 3-dots and 3 lines).**
diff --git a/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md
b/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md
index bd8173a4e33..befaa24ed39 100644
--- a/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md
+++ b/dev/breeze/doc/adr/0003-bootstrapping-virtual-environment.md
@@ -88,7 +88,7 @@ of the CI is stored in the same repository as the source code
of the
application it tests and part of the Breeze functions are shared with CI.
In the future when breeze stabilizes and its update cadence will be
-much slower (which is likele as it happened with the Breeze predecessor)
+much slower (which is likely as it happened with the Breeze predecessor)
there could be an option that Breeze is installed as separate package and
same released Breeze version could be ued to manage multiple Airflow
versions, for that we might want to release Breeze as a separate package
@@ -173,7 +173,7 @@ The alternatives considered were:
additional tool that needs to be installed and it lacks
the automation of checking and recreation of the virtualenv
when needed (you need to manually run nox to update environment)
- Alsoi it is targeted for building multiple virtualenv
+ Also it is targeted for building multiple virtualenv
for tests - it has nice pytest integration for example, but it
lacks support for managing editable installs for a long time.
@@ -203,5 +203,5 @@ having to install any prerequisites. The virtualenv used by
breeze will be hidden from the user, and used behind the
scenes - and the dependencies used will be automatically
installed when needed. This will allow to seamlessly
-integrate Breeze tool in the develiopment experience without
+integrate Breeze tool in the development experience without
having to worry about extra maintenance needed.
diff --git
a/dev/breeze/doc/adr/0005-preventing-using-contributed-code-when-building-images.md
b/dev/breeze/doc/adr/0005-preventing-using-contributed-code-when-building-images.md
index 765a77c599c..fc9831c1771 100644
---
a/dev/breeze/doc/adr/0005-preventing-using-contributed-code-when-building-images.md
+++
b/dev/breeze/doc/adr/0005-preventing-using-contributed-code-when-building-images.md
@@ -45,7 +45,7 @@ As described in [4. Using Docker images as test
environment](0004-using-docker-i
Airflow CI system uses CI Docker image as consistent test execution
environment. This environment provides
cacheability and rebuild capabilities that allow the image to be rebuilt
quickly, incrementally based on
previous version of the images - whenever any of the source code, Python
dependencies, System dependencies
-are changed (in optimal way depending on the change). However, even with
optimalizations, rebuilding
+are changed (in optimal way depending on the change). However, even with
optimizations, rebuilding
the image might take quite some time (when only sources change ~ 1 minute, but
when system dependencies
change ~ 10 minutes). In certain cases we run (for the same Python version) 20
jobs that require the same
image as the environment, which in extreme cases would mean 20x10 = 200 build
minutes on CI to
diff --git a/dev/breeze/doc/adr/0011-unified-communication-with-the-users.md
b/dev/breeze/doc/adr/0011-unified-communication-with-the-users.md
index 6de55bac57f..24f46e78bec 100644
--- a/dev/breeze/doc/adr/0011-unified-communication-with-the-users.md
+++ b/dev/breeze/doc/adr/0011-unified-communication-with-the-users.md
@@ -40,7 +40,7 @@ Accepted
## Context
We communicate with the user via messages printed in get_console() And we
should
-make sure we communicate the msssages in a consistent way so that the users
would
+make sure we communicate the messages in a consistent way so that the users
would
understand:
* whether verification of a condition succeeded
diff --git a/dev/breeze/doc/ci/04_selective_checks.md
b/dev/breeze/doc/ci/04_selective_checks.md
index 0131a919c19..7944141e60d 100644
--- a/dev/breeze/doc/ci/04_selective_checks.md
+++ b/dev/breeze/doc/ci/04_selective_checks.md
@@ -371,7 +371,7 @@ We have the following Groups of files for CI that determine
which tests are run:
* `UI files` - those are files for the new full React UI (useful to determine
if UI tests should run)
* `System test files` - those are the files that are part of system tests
(system tests are not automatically
run in our CI, but Airflow stakeholders are running the tests and expose
dashboards for them at
- [System Test
Dashbards](https://airflow.apache.org/ecosystem/#airflow-provider-system-test-dashboards)
+ [System Test
Dashboards](https://airflow.apache.org/ecosystem/#airflow-provider-system-test-dashboards)
* `Kubernetes files` - determine if any of Kubernetes related tests should be
run
* `All Python files` - if none of the Python file changed, that indicates that
we should not run unit tests
* `All source files` - if none of the sources change, that indicates that we
should probably not build
diff --git a/dev/breeze/doc/ci/05_workflows.md
b/dev/breeze/doc/ci/05_workflows.md
index d8aa134bb75..b06daa28894 100644
--- a/dev/breeze/doc/ci/05_workflows.md
+++ b/dev/breeze/doc/ci/05_workflows.md
@@ -84,7 +84,7 @@ CI/CD scripts or changes to the CI/CD workflows). In this
case the PR is
run in the context of the "apache/airflow" repository and has WRITE
access to the GitHub Container Registry.
-When the PR changes important files (for example
`generated/provider_depdencies.json` or
+When the PR changes important files (for example
`generated/provider_dependencies.json` or
`pyproject.toml` or `hatch_build.py`), the PR is run in "upgrade to newer
dependencies" mode -
where instead of using constraints to build images, attempt is made to upgrade
all dependencies to latest versions and build images with them. This way we
check how Airflow behaves when the
diff --git a/docker-context-files/.README.md b/docker-context-files/.README.md
index 776555b1442..c54e9c910fb 100644
--- a/docker-context-files/.README.md
+++ b/docker-context-files/.README.md
@@ -22,7 +22,7 @@ This folder is part of the Docker context.
Most of other folders in Airflow are not part of the context in order to make
the context smaller.
The Production [Dockerfile](../Dockerfile) image copies the
[docker-context-files](.) folder to the
-image context forthe build segment, so content of the folder is available in
the `/docker-context-files`
+image context for the build segment, so content of the folder is available in
the `/docker-context-files`
folder inside the build image. You can store constraint files and wheel
packages there that you want to install as PYPI packages and refer to those
packages using
`--airflow-constraints-location /docker-context-files/constraints.txt` flag for
diff --git
a/providers/apache/hive/tests/system/apache/hive/example_twitter_README.md
b/providers/apache/hive/tests/system/apache/hive/example_twitter_README.md
index 713ed4ae243..1b2ad826f8d 100644
--- a/providers/apache/hive/tests/system/apache/hive/example_twitter_README.md
+++ b/providers/apache/hive/tests/system/apache/hive/example_twitter_README.md
@@ -38,8 +38,8 @@
***Example Structure:*** In this example dag, we are collecting tweets for
four users account or twitter handle. Each twitter handle has two channels,
incoming tweets and outgoing tweets. Hence, in this example, by running the
fetch_tweet task, we should have eight output files. For better management,
each of the eight output files should be saved with the yesterday's date (we
are collecting tweets from yesterday), i.e. toTwitter_A_2016-03-21.csv. We are
using two kinds of operators (Bas [...]
The python functions here are just placeholders. In case you are interested to
actually make this Dag fully functional, first start with filling out the
scripts as separate files and importing them into the Dag with absolute or
relative import. My approach was to store the retrieved data in memory using
Pandas dataframe first, and then use the built in method to save the CSV file
on hard-disk.
-The eight different CSV files are then put into eight different folders within
HDFS. Each of the newly inserted files are then loaded into eight different
external hive tables. Hive tables can be external or internal. In this case, we
are inserting the data right into the table, and so we are making our tables
internal. Each file is inserted into the respected Hive table named after the
twitter channel, i.e. toTwitter_A or fromTwitter_A. It is also important to
note that when we created [...]
-As most probably these folders and hive tables doesn't exist in your system,
you will get an error for these tasks within the Dag. If you rebuild a function
Dag from this example, make sure those folders and hive tables exists. When you
create the table, keep the consideration of table partitioning and declaring
comma as the row deliminator in your mind. Furthermore, you may also need to
skip headers on each read and ensure that the user under which you have Airflow
running has the right [...]
+The eight different CSV files are then put into eight different folders within
HDFS. Each of the newly inserted files are then loaded into eight different
external hive tables. Hive tables can be external or internal. In this case, we
are inserting the data right into the table, and so we are making our tables
internal. Each file is inserted into the respected Hive table named after the
twitter channel, i.e. toTwitter_A or fromTwitter_A. It is also important to
note that when we created [...]
+As most probably these folders and hive tables doesn't exist in your system,
you will get an error for these tasks within the Dag. If you rebuild a function
Dag from this example, make sure those folders and hive tables exists. When you
create the table, keep the consideration of table partitioning and declaring
comma as the row delimiter in your mind. Furthermore, you may also need to skip
headers on each read and ensure that the user under which you have Airflow
running has the right p [...]
```
CREATE TABLE toTwitter_A(id BIGINT, id_str STRING
diff --git a/providers/apache/tinkerpop/docs/connections/tinkerpop.rst
b/providers/apache/tinkerpop/docs/connections/tinkerpop.rst
index 50b82c9f4bc..3bb6d74f49f 100644
--- a/providers/apache/tinkerpop/docs/connections/tinkerpop.rst
+++ b/providers/apache/tinkerpop/docs/connections/tinkerpop.rst
@@ -27,7 +27,7 @@ The Gremlin connection type enables integrations with Gremlin
Server.
Authenticating to Gremlin
---------------------------
-Authenticate to Gremlin using the `Germlin python client default authentication
+Authenticate to Gremlin using the `Gremlin python client default authentication
<https://tinkerpop.apache.org/docs/current/reference/#gremlin-python-configuration>`_.
Default Connection IDs
diff --git a/providers/microsoft/azure/docs/connections/azure_batch.rst
b/providers/microsoft/azure/docs/connections/azure_batch.rst
index 887b60fea5d..fe2c9f656ae 100644
--- a/providers/microsoft/azure/docs/connections/azure_batch.rst
+++ b/providers/microsoft/azure/docs/connections/azure_batch.rst
@@ -71,7 +71,7 @@ For example:
.. code-block:: bash
- export
AIRFLOW_CONN_AZURE_BATCH_DEFAULT='azure-batch://batch%20acount:batch%20key@?account_url=mybatchaccount.com'
+ export
AIRFLOW_CONN_AZURE_BATCH_DEFAULT='azure-batch://batch%20account:batch%20key@?account_url=mybatchaccount.com'
.. _DefaultAzureCredential:
https://docs.microsoft.com/en-us/python/api/overview/azure/identity-readme?view=azure-python#defaultazurecredential
diff --git a/shared/README.md b/shared/README.md
index 1cfd30a0b46..65374340399 100644
--- a/shared/README.md
+++ b/shared/README.md
@@ -119,7 +119,7 @@ shared_distributions = [
]
```
-This allows `prek` check to automatically verify if the shared distributio is
properly configured in
+This allows `prek` check to automatically verify if the shared distribution is
properly configured in
your source tree and `pyproject.toml`.
You should also have `_shared` folder created in your source tree to be able
to symlink the shared
@@ -133,7 +133,7 @@ but you can also do it manually (for each shared
distribution used):
`ln -s ../../shared/timezones/src/airflow_shared/timezones
src/airflow/sdk/_shared/timezones`
* adding force-include in your `pyproject.toml` to have hatchling copy the
source files instead of
- symling when `.sdist` distribution is built:
+ symlink when `.sdist` distribution is built:
```toml
[tool.hatch.build.targets.sdist.force-include]
