Don't trigger line-length on lines that are just a single unbreakable string followed by a space and a backslash

[taladar]

It seems currently line-length is smart enough not to trigger when a line is just a single unbreakable string but if e.g. a yaml value is a shell script with line continuation backslashes after such a single unbreakable string it still triggers.

So, e.g. if we have a .gitlab-ci.yaml with

job:
  script:
    - |-
      curl \
        "https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer"

this already does not trigger length but

job:
  script:
    - |-
      curl \
        "https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer" \
       -o output.json

the very same line just with a shell line continuation at the end now does, even though our options to break it up have not really improved.

My suggestion would be to also automatically exclude lines like that from line-length lints, especially since white-listing individual lines in the middle of multi-line shell commands like that also does not really work.

[andrewimeson]

I don't think yamllint should try and make assumptions about the data like this would require, although backslashes are fairly common for escaping newlines in programming languages (but not all YAML usage is containing code).

In your specific example you could solve it by moving the option before the URL

job:
  script:
    - |-
      curl \
       -o output.json \
       "https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer"

[taladar]

This was just an example. The actual command has about a dozen options and three of them are too long.

[adrienverge]

Hello,

Like @andrewimeson, I understand the request because \ at the end of lines is quite common. A new option in the line-length rule could be a solution, but in most cases (maybe all?) you just need not to use |.

Would this work for you? If not, why?

job:
  script:
    -
      curl
        "https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer"
        -o output.json

or:

job:
  script:
    - >-
      curl
        "https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer"
        -o output.json

[andrewimeson]

My suggestion here is a little off-topic to the yamllint rules question, but I think it may be helpful to someone. I have shifted in shell scripting to storing options in an array instead of spreading them out over multiple lines with \, mainly because then I can add comments to the array, but also because it's easier to conditionally add options (like if I make a shell function to wrap curl to an API) by doing my conditions and appending to the array.

Here's a simple example without any of the conditionals

curl_opts=(
    --show-error
    --fail # treat HTTP errors as errors
    --header "Authorization: token $TOKEN"
    --no-progress-meter
    --retry 5           # number of retries with transient errors
    --retry-max-time 40 # max cumulative retry time
    --dump-header /dev/stderr
)

curl -X HEAD "${curl_opts[@]}" \
    https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer

I do this in both normal shell scripts, and shell embedded in YAML.

[taladar]

The version without backslashes won't work because the actual script has more than one command.

The array variant might work in the case of bash scripts but from what I can tell arrays do not exist in POSIX sh so in situations where the code is just interpreted by /bin/sh that won't work.

[andrewimeson]

The version without backslashes won't work because the actual script has more than one command.

You can get a real \n by doing a blank line. Leading spaces also work, but are less intuitive.

job:
  script:
    - >-
      curl
      -o output.json
      "https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer"

      echo second command

EDIT: I tend not to like using > or >- for embedded scripts. I'd much prefer the | style and using the language's escaping for newlines, but obviously that's the problem you're running into in this case. If it's a simple enough series of commands without much complex shell syntax or flow control, I think >/>- are fine.

[taladar]

That might actually work, I will give that a try, thank you for the help. I will have to reformat the file and ran out of time for today but thanks for all the quick help. I just wish YAML wasn't such an unreadable mess of a file format.

[taladar]

It seems lines that are indented also receive an extra newline which hurts the readability of the script inside the YAML file since all parameters need to be on the same indentation level as the command or they will be separated by newlines.

[andrewimeson]

Another workaround very specific to this case would be assigning the URL to a variable first

job:
  script:
    - |-
      URL="https://very-long-unbreakable-url.example.net/just/some/more/filler/to/make/this/longer/and/longer/and/longer/and/longer"
      curl \
       "$URL" \
       -o output.json