[Automated] Update yq CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to yq CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[claude]

Code Review

This is an automated PR updating the Usage:
yq [flags]
yq [command]

Examples:

yq tries to auto-detect the file format based off the extension, and defaults to YAML if it's unknown (or piping through STDIN)

Use the '-p/--input-format' flag to specify a format type.

cat file.xml | yq -p xml

read the "stuff" node from "myfile.yml"

yq '.stuff' < myfile.yml

update myfile.yml in place

yq -i '.stuff = "foo"' myfile.yml

print contents of sample.json as idiomatic YAML

yq -P -oy sample.json

Available Commands:
completion Generate the autocompletion script for the specified shell
eval (default) Apply the expression to each document in each yaml file in sequence
eval-all Loads all yaml documents of all yaml files and runs expression once
help Help about any command

Flags:
-C, --colors force print with colors
--csv-auto-parse parse CSV YAML/JSON values (default true)
--csv-separator char CSV Separator character (default ,)
--debug-node-info debug node info
-e, --exit-status set exit status if there are no matches or null or false is returned
--expression string forcibly set the expression argument. Useful when yq argument detection thinks your expression is a file.
--from-file string Load expression from specified file.
-f, --front-matter string (extract|process) first input as yaml front-matter. Extract will pull out the yaml content, process will run the expression against the yaml content, leaving the remaining data intact
--header-preprocess Slurp any header comments and separators before processing expression. (default true)
-h, --help help for yq
-I, --indent int sets indent level for output (default 2)
-i, --inplace update the file in place of first file given.
-p, --input-format string [auto|a|yaml|y|kyaml|ky|json|j|props|p|csv|c|tsv|t|xml|x|base64|uri|toml|hcl|h|lua|l|ini|i] parse format for input. (default "auto")
--lua-globals output keys as top-level global variables
--lua-prefix string prefix (default "return ")
--lua-suffix string suffix (default ";\n")
--lua-unquoted output unquoted string keys (e.g. {foo="bar"})
-M, --no-colors force print with no colors
-N, --no-doc Don't print document separators (---)
-0, --nul-output Use NUL char to separate values. If unwrap scalar is also set, fail if unwrapped scalar contains NUL char.
-n, --null-input Don't read input, simply evaluate the expression given. Useful for creating docs from scratch.
-o, --output-format string [auto|a|yaml|y|kyaml|ky|json|j|props|p|csv|c|tsv|t|xml|x|base64|uri|toml|hcl|h|shell|s|lua|l|ini|i] output format type. (default "auto")
-P, --prettyPrint pretty print, shorthand for '... style = ""'
--properties-array-brackets use [x] in array paths (e.g. for SpringBoot)
--properties-separator string separator to use between keys and values (default " = ")
--security-disable-env-ops Disable env related operations.
--security-disable-file-ops Disable file related operations (e.g. load)
--shell-key-separator string separator for shell variable key paths (default "")
-s, --split-exp string print each result (or doc) into a file named (exp). [exp] argument must return a string. You can use $index in the expression as the result counter. The necessary directories will be created.
--split-exp-file string Use a file to specify the split-exp expression.
--string-interpolation Toggles strings interpolation of (exp) (default true)
--tsv-auto-parse parse TSV YAML/JSON values (default true)
-r, --unwrapScalar unwrap scalar, print the value with no quotes, colours or comments. Defaults to true for yaml (default true)
-v, --verbose verbose mode
-V, --version Print version information and quit
--xml-attribute-prefix string prefix for xml attributes (default "+@")
--xml-content-name string name for xml content (if no attribute name is present). (default "+content")
--xml-directive-name string name for xml directives (e.g. ) (default "+directive")
--xml-keep-namespace enables keeping namespace after parsing attributes (default true)
--xml-proc-inst-prefix string prefix for xml processing instructions (e.g. ) (default "+p")
--xml-raw-token enables using RawToken method instead Token. Commonly disables namespace translations. See https://pkg.go.dev/encoding/xml#Decoder.RawToken for details. (default true)
--xml-skip-directives skip over directives (e.g. )
--xml-skip-proc-inst skip over process instructions (e.g. )
--xml-strict-mode enables strict parsing of XML. See https://pkg.go.dev/encoding/xml for more details.
-c, --yaml-compact-seq-indent Use compact sequence indentation where '- ' is considered part of the indentation.
--yaml-fix-merge-anchor-to-spec Fix merge anchor to match YAML spec. Will default to true in late 2025

Use "yq [command] --help" for more information about a command. CLI options generator timestamp.

Change Summary

The only change is a timestamp update in :

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-01T03:12:17.1379905Z

Observations

No functional changes: Despite the PR description mentioning "Updated options classes to reflect latest CLI documentation", "Added new commands if any were detected", and "Updated option types and descriptions", the actual diff contains only a timestamp update. This means the generator ran and found no changes in the yq CLI options since the last generation — the yq CLI interface has not changed between runs.

Correctness: The timestamp update is accurate and reflects the regeneration time. This is appropriate behavior — the generator correctly records when it last ran, even when no functional changes were detected.

PR description boilerplate: The PR template appears to always list all possible change categories regardless of what actually changed. It might be worth making the template more dynamic (e.g., only listing the categories where actual changes occurred) to avoid misleading descriptions for timestamp-only updates. That said, this is a minor concern for an automated workflow.

Verdict

The change is correct and safe to merge. The auto-merge enabled via squash is appropriate for this type of automated dependency/options update.

[claude]

Code Review

This is an automated PR updating the yq CLI options generator timestamp.

Change Summary

The only change is a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-01T03:12:17.1379905Z

Observations

No functional changes: Despite the PR description mentioning "Updated options classes to reflect latest CLI documentation", "Added new commands if any were detected", and "Updated option types and descriptions", the actual diff contains only a timestamp update. This means the generator ran and found no changes in the yq CLI options since the last generation — the yq CLI interface has not changed between runs.

Correctness: The timestamp update is accurate and reflects the regeneration time. This is appropriate behavior — the generator correctly records when it last ran, even when no functional changes were detected.

PR description boilerplate: The PR template appears to always list all possible change categories regardless of what actually changed. It might be worth making the template more dynamic (e.g., only listing the categories where actual changes occurred) to avoid misleading descriptions for timestamp-only updates. That said, this is a minor concern for an automated workflow.

Verdict

The change is correct and safe to merge. The auto-merge enabled via squash is appropriate for this type of automated dependency/options update.

[claude]

Code Review

This is an automated PR updating the yq CLI options generator timestamp.

Change Summary

The only change is a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-01T03:12:17.1379905Z

Observations

No functional changes: Despite the PR description mentioning Updated options classes to reflect latest CLI documentation, Added new commands if any were detected, and Updated option types and descriptions, the actual diff contains only a timestamp update. This means the generator ran and found no changes in the yq CLI options since the last generation - the yq CLI interface has not changed between runs.

Correctness: The timestamp update is accurate and reflects the regeneration time. This is appropriate behavior - the generator correctly records when it last ran, even when no functional changes were detected.

PR description boilerplate: The PR template appears to always list all possible change categories regardless of what actually changed. It might be worth making the template more dynamic (e.g., only listing the categories where actual changes occurred) to avoid misleading descriptions for timestamp-only updates. That said, this is a minor concern for an automated workflow.

Verdict

The change is correct and safe to merge. The auto-merge enabled via squash is appropriate for this type of automated dependency/options update.

[claude]

Code Review

This is a follow-up review. Previous reviews (from 2026-03-01) already covered this PR and noted it was a timestamp-only update with no functional changes.

Current Change

The diff still shows only a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-08T03:08:55.2164538Z

The PR has been regenerated (the timestamp advanced from the 2026-03-01 intermediate value to 2026-03-08), which continues to confirm that the yq CLI interface has not changed — the generator ran again and found nothing new to update.

Previous Review Feedback Status

The previous reviews raised a minor suggestion about making the PR description template more dynamic (only listing change categories where actual changes occurred). This has not been addressed, but it remains a low-priority improvement to the automated workflow rather than a blocker.

Verdict

The change is correct and safe to merge. No functional changes are present, and the auto-merge via squash remains appropriate for this type of automated timestamp-only options refresh.

[claude]

Code Review

This is another follow-up review. Previous reviews (from 2026-03-01 and 2026-03-08) have already covered this PR in detail.

Current Change

The diff again contains only a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-15T03:14:35.9773144Z

This is now the fourth weekly regeneration cycle captured in this PR's history, and each time the yq CLI interface has remained unchanged. The generator is working correctly — it records when it last ran and produces no functional diff because no yq options have changed.

Previous Review Feedback Status

Prior reviews raised a suggestion about making the PR description template more dynamic (only listing change categories where actual changes occurred, rather than always listing all possible categories). This has not been addressed across multiple review cycles.

While still low-priority, I'll reiterate the suggestion with a bit more detail: when the generator detects that only a timestamp was updated (i.e., no options classes changed), the PR body could conditionally include a note like "No functional changes detected — timestamp refreshed only." This would save reviewers from having to inspect the diff to determine that nothing meaningful changed. The automated workflow could check git diff --stat after generation and branch the PR description accordingly.

Verdict

The change is correct and safe to merge. No functional changes are present, and auto-merge via squash remains appropriate.

[claude]

Code Review

This is another follow-up review. Previous reviews (from 2026-03-01, 2026-03-08, and 2026-03-15) have already covered this PR in detail.

Current Change

The diff again contains only a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-22T03:12:19.0225468Z

This is now the fifth weekly regeneration cycle captured in this PR's history, and each time the yq CLI interface has remained unchanged.

Previous Review Feedback Status

All previous reviews raised a suggestion about improving the PR description template to be more dynamic — specifically, when the generator detects only a timestamp change, the PR body should reflect that clearly (e.g., "No functional changes detected — timestamp refreshed only.") rather than always listing all possible change categories.

This suggestion has not been addressed across five review cycles. Since this is an automated workflow, the fix would need to go into the generator or the workflow script that creates the PR. Given that timestamp-only PRs appear to be common (every week for this tool), the misleading description continues to add unnecessary reviewer overhead.

Architectural suggestion: Consider skipping PR creation entirely when no functional changes are detected (only the timestamp differs). The generator could compare the current generated output against the committed version (excluding the timestamp line) and only open a PR when actual content changes exist. This would eliminate noise from frequent automated PRs that carry no meaningful updates.

Verdict

The change is correct and safe to merge. No functional changes are present, and auto-merge via squash remains appropriate.

[claude]

Code Review

This is a follow-up review. Previous reviews (from 2026-03-01, 2026-03-08, 2026-03-15, and 2026-03-22) have already covered this PR in detail.

Current Change

The diff again contains only a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-03-29T03:36:57.7932526Z

This is now the sixth weekly regeneration cycle captured in this PR's history, and each time the yq CLI interface has remained unchanged. The generator continues to work correctly — recording when it last ran and producing no functional diff because no yq options have changed.

Previous Review Feedback Status

All prior reviews raised the same suggestion: when the generator detects only a timestamp change, the automated workflow should either:

1. Skip creating a PR entirely — compare generated output against committed content (excluding the timestamp line) and only open a PR when actual content changes exist. This is the more impactful improvement and would eliminate the recurring noise entirely.
2. Update the PR description dynamically — reflect the absence of functional changes explicitly (e.g., "No functional changes detected — timestamp refreshed only.") rather than always listing all possible change categories.

This suggestion has not been addressed across six review cycles. Given the pattern, I would strongly encourage implementing option 1 in the generator or CI workflow to avoid weekly no-op PRs.

Verdict

The change is correct and safe to merge. No functional changes are present, and auto-merge via squash remains appropriate for this automated refresh.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	✅ 0 (≤ 20 complexity)

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[claude]

Code Review

This is a follow-up review. Previous reviews (from 2026-03-01 through 2026-03-29) have already covered this PR in detail across seven review cycles.

Current Change

The diff again contains only a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-04-05T03:14:51.7551241Z

This is now the eighth weekly regeneration cycle captured in this PR's history, and each time the yq CLI interface has remained unchanged.

Previous Review Feedback Status

All prior reviews have consistently raised the same architectural suggestion, which has not been addressed across eight review cycles:

Skip PR creation entirely when no functional changes are detected. The generator or CI workflow should compare the generated output against the committed content (excluding the timestamp line) and only open a PR when actual content changes exist. This would eliminate the weekly no-op PRs that carry no meaningful updates.

Since this same PR has been accumulating weekly timestamp commits without ever merging, it would also be worth considering whether the auto-merge configuration is working as intended — this PR has been open since at least early February 2026 and has gone through at least 8 regeneration cycles.

Verdict

The change is correct and safe to merge. No functional changes are present, and auto-merge via squash remains appropriate for this automated refresh.

[claude]

Code Review

This is a follow-up review. Previous reviews (from 2026-03-01 through 2026-04-05) have already covered this PR in detail across eight review cycles.

Current Change

The diff again contains only a timestamp update in AssemblyInfo.Generated.cs:

• Before: 2026-02-15T03:12:04.5805950Z
• After: 2026-04-12T03:34:31.1277820Z

This is now the ninth weekly regeneration cycle captured in this PR's history, and each time the yq CLI interface has remained unchanged. The generator is working correctly — it records when it last ran and produces no functional diff because no yq options have changed.

Previous Review Feedback Status

All prior reviews have consistently raised the same architectural suggestion, which remains unaddressed across nine review cycles:

Skip PR creation entirely when no functional changes are detected. The generator or CI workflow should compare the generated output against the committed content (excluding the timestamp line) and only open a PR when actual content changes exist. This would eliminate the recurring weekly no-op PRs.

Concretely, this could be implemented in the workflow script after generation by running something like:

# Exclude the timestamp line from the diff check
if git diff --unified=0 | grep -v "GeneratedAt" | grep -q "^[+-]"; then
  # Functional changes exist — create/update the PR
else
  # No functional changes — skip or close the PR
  gh pr close <pr-number> --comment "No functional changes detected; closing to reduce noise."
fi

Additionally, this PR has now been open for nearly two months without merging despite having auto-merge enabled. It would be worth investigating why auto-merge hasn't triggered — it's possible a required status check is consistently failing or the branch protection rules are preventing it.

Verdict

The change is correct and safe to merge. No functional changes are present, and auto-merge via squash remains appropriate.

[claude]

Code Review

This is a follow-up review. Previous reviews (from 2026-03-01 through 2026-04-12) covered nine cycles of timestamp-only regenerations. This cycle is the first one with actual functional changes.

What Changed

1. #nullable enable added to all generated files — YqEvalAllOptions.Generated.cs, YqEvalOptions.Generated.cs, YqOptions.Generated.cs, IYq.Generated.cs, Yq.Generated.cs
2. New SecurityEnableSystemOperator property added to YqEvalAllOptions and YqEvalOptions, mapping to --security-enable-system-operator
3. Timestamp bump in AssemblyInfo.Generated.cs to 2026-04-19T03:37:02Z

Assessment

#nullable enable: Positive improvement. Enabling nullable reference types in generated files brings them in line with modern C# practices and helps consumers catch null-related issues at compile time. No issues here.

SecurityEnableSystemOperator: This is a security-sensitive flag — the yq documentation describes it as enabling the system operator, which allows executing arbitrary external shell commands from within yq expressions. The binding is correct and clearly named. The XML doc comment accurately describes the behavior. No issues with the implementation itself.

One observation worth noting for consumers of this library: setting SecurityEnableSystemOperator = true combined with user-controlled yq expressions creates a command injection risk. Since this mirrors the upstream CLI flag's own risk profile, no change is needed in the generated code — but it may be worth adding a security note to any higher-level documentation if this flag is exposed in user-facing APIs.

Previous Review Feedback Status

Prior reviews repeatedly suggested skipping PR creation entirely when no functional changes are detected. This cycle demonstrates that the current approach (always creating a PR) does eventually surface real changes — which is the correct trade-off. That suggestion is less urgent now that this PR has confirmed value.

Verdict

The changes are correct and safe to merge. The #nullable enable addition and the new SecurityEnableSystemOperator property are faithful, well-typed bindings to the upstream yq CLI. Auto-merge via squash is appropriate.