Add YAML-based help texts for auto-generated airflowctl commands

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[justinpakzad]

---

This PR attempts to implement a YAML based approach to map airflow-ctl help texts. The idea behind this was to have a single source of truth that can be easy to validate in the pre-commit (see the linked issue for a bit more detail). This targets the auto-generated commands. I also created a prek hook check_airflowctl_help_texts that ensures all the auto-generated commands have their respective help texts.

A couple of notes on the approach:
I created a help_texts.yaml file in the ctl directory with all the group/subcommand to help text mappings. Not sure if there is a specific naming convention we would like to follow so happy to change that if needed. Inside the CommandFactory() class we read the help_texts into an instance variable and then use it to look up and assign the help text in the _create_group_commands_from_operation() method. Added an additional test case that tests the help texts from YAML are used for auto-generated commands.

I moved the parse_operations() function into the common prek utils so that it can be used in the new hook & the airflowctl command coverage (which is where it was originally) scripts without duplicating code. The check goes through the auto-generated commands, performs a look up against the yaml, collects any that are missing, and then will output a message describing which are missing and the file they should be added to.

Curious to hear if this approach makes sense and open to any suggestions.

closes: #57632

Was generative AI tooling used to co-author this PR?

• Yes (Claude Sonnet 4.6 for generating the yaml with the help texts)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bugraoz93]

Nice :) Thanks for the PR!

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test