5 ms·

> Still, totally fine for pretty much everything I’ve needed it for. Try writing non-trivial multi-line bash snippets for Gitlab CI in yaml. These change your

• andrei_says_ 3y ago
  1. “ writing non-trivial multi-line bash snippets for Gitlab CI” sounds intimidating even without the “in yaml” part. I don’t want to do it. 2. “In yaml” could be a fun way to end all kinds of sentences describing challenging tasks ;)
  • kunley 3y ago
    You don't want do do it, erm, but maybe people need to do it, because, huh, it's not an unreasonable thing to be put in the CI, right?
    • maccard 3y ago
      Every CI project I've maintained in the last 10 years has dispatched the logic to a script stored in version control.
      • kunley 3y ago
        YMMV. Other part of the world might not like too many levels of indirection, and would consider their approach a good practice.
• andreareina 3y ago
  I have to look them up every. time. but YAML has a sigil for multi-line strings and lets you choose between strip/preserve newlines/leading whitespace. I still don't like YAML though
• npn 3y ago
  because a sane people would delegate the task to a separated script instead.
• vb-8448 3y ago
  I wrote some non-trivial multi-line bash snippets for Gitlab CI in yaml and didn't find anything annoying. Any example that gave you problem?
• horse666 3y ago
  I would suggest never doing that, because it makes it impossible, or at least very difficult, to: 1. Lint the code using ShellCheck, which IMO is essential for any shell 2. Run and test that code locally, or anywhere outside of the CI tool It’s only marginally less convenient to externalise the code into a .sh file and load it in CI.