I've just wasted 2 hours fixing an issue with a GitLab CI YAML definition, all because of a single colon:

echo "Detected changes: compiling new locks"

I swear to god, whoever thought it is a good idea to use YAML for CI scripts should rot in hell.

  • 2
    While some people might roast me now...

    Python YAML is easy.

    And there is an YAML tool like jq.


    I fucking hate - absolutely hate - YAML as it sacrificed structure to save a few characters imho.

    But at least there are possibilities to validate them :/ still major pain in the arse.

    Many of my configuration repositories for backup / distribution of configuration have a separate script to validate YAML... It's brain damaged, but necessary. :(
  • 1
    gitlab CICD has linter. Use the godawful fuken thing.
    My take on the whole yaml thing is "meh". Saw worse (jenkins), but also saw better.

    Wait until you will need to stop a long running script step, or update an env var between stages... then you will realllllly hate gitlab ci.
  • 0
    If you have a better-formatted structured data suggestion, then be my guest to use that and then convert it to yaml.

    Yaml is the simplest to read and most efficient to write; once you start using Kubernetes you'll understand.
  • 2
    @arcsector efficient


    It's not efficient If you have to convert it from another format or you have to triple check it with linting, validation and config checker to make sure it didn't have a mistake.

    I love JSON. It's sane. If we could use JSON as YAML 1.2 says everywhere where YAML is expected, I'd be happy...

    Especially in larger configurations - e.g. prometheus YAML configuration with dozens of targets - it's a cludgy mess.
  • 0
    I like vagrant's configuration is plain ruby.

    Or python's setup.py

    I think plain text files in whatever format are messy and deserve a slow death.
  • 0
    @IntrusionCM i really have nothing against JSON, but people who say YAML is difficult because of the whitespace are the same people that don't like Golang because it uses whitespace differently than C.

    You didnt really specify why you dont like it, all you said was that you dont like it when you convert or that you have to use linting and config checkers, which you would normally use on JSON anyways.

    Reminder that JSON is still new, and I would much prefer everything be in INI because most languages have readily available parsers for it built-in, and its a much simpler syntax than JSON, and it supports comments by default. But i might be insane for that since I've been using them for so long that it's just second nature to me.
  • 1

    "YAML as it sacrificed structure to save a few characters imho."

    - you are partially correct in the assumption about the whitespace, YAML is clearly lacking a _visible_ structure
  • 0
  • 1
    Yeah. and it broke - as I expected it.

    Correct would be:

    # Alertmanager configuration

    # Alertmanager configuration



    - static_configs:

    - targets:

    - prometheus:9093

    Guess the copy and pasting gobbled up the newlines or sth. like that. Sorry.

    The thing about the structureless approach to save a few keystrokes is that it's really hard to read as soon as we leave the dandy world of "it's a simple array or a simple object".

    The prometheus configuration goes sometimes 5-7 levels deep.

    Trying to ungobble that whitespace indentation is like klingon painsticks up your butt.

    Another good example, taken from Elasticsearch -/ Ingest pipelines:

    - date:

    if: ctx.event?.timezone == null && ctx.haproxy?.request_date != null

    field: haproxy.request_date

    target_field: '@timestamp'


    - dd/MMM/yyyy:HH:mm:ss.SSS

    - MMM dd HH:mm:ss


    - append:

    field: error.message

    value: '{{ _ingest.on_failure_message }}'
  • 1
    Ok. Devrant really hates newlines. :/
  • 1
    @IntrusionCM all good; i get what you mean, i just dont come into k8s deployments that are 10 levels deep, and if I do they're using 4pt indent or higher. Regardless, they both definitely have their strengths, although i would like to say that I definitely have become jaded against JSON due to javascript's insistent usage of it for everything.
  • 0
    @magicMirror Gitlab linter message doesn't even show on which line it is failing.
  • 0
    @arcestor Go and try doing multiline bash scripts in YAML, I dare you.

    It is _not_ the right format for that. YAML is meant to describe structured information, but, formally speaking, when it has no concept of the grammar of the script you're trying to put into it, you have to process your code into something that YAML accepts, which is a huge pain in the butt. That is, unless someone implements converting from YAML to the language itself, which AFAIR no CICD solution does.

    Then there is the issue of every parser implementing details a bit differently (e.g. GL parser ≠ Python yaml module), error handling being non-existent (we have 50 years of formal language research that shows the right way to do it, most YAML parsers throw it out the window), and, oh my god, the security issues...

    It's a bloated format that's still used _only_ because you can't template in vanilla JSON.
  • 0
    @GittinGudder hence the "godawful fuken" prefix.
    I use it by removing stages/chunks fr the yaml to to locate the problem line.
  • 0
    @magicMirror ye, fair, that's what I did. It was tedious as f**k though.
Add Comment