Avoid excessive indentation in shell commands #927
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The project's GitHub Actions workflows and tasks contain complex shell command lines.
With the use of the line continuation operator, these commands can be split into multiple code lines. This improves readability by providing a visualization of the command structure. It also improves maintainability by making diffs for changes to these commands more clear.
The readability can be further improved by indentation of the subsequent lines of the command in a manner that visually conveys the structure.
Previously, in cases where multiple commands are chained via control or list operators, the subsequent commands were indented relative to the prior command in the chain. Although this did help to visually convey the structure, it also resulted in excessive levels of indentation. It also resulted in some visual ambiguity between indentation used for arguments to a command, and that for subsequent commands in the chain. For these reasons, the determination was made to not indent the subsequent commands in the chain. The structure is communicated by placing the operator linking the commands on a dedicated line.