Am I the only one who finds YAML to be difficult to reason about? I find that if the config is that complex, JSON or XML to be much easier to deal with. I think of TOML as the best balance between ease of use and expressiveness.
These ORBs sound similar to docker images, I’m surprised they didn’t offer a comparison, like “why not docker?”, or did I miss it?
executors:
alpine:
docker:
- image: alpine:3.6
parameters:
webhook_url:
description: URL to Slack webhook
type: string
message:
description: Message to post to Slack
type: string
commands:
notify:
description: "Notify Slack"
executor: alpine
steps:
- run:
name: Notify Slack
command: |
curl -X POST -H 'Content-Type: application/json' --data "{ \
\"attachments\": [ \
{ \
\"fallback\": \"<<parameters.message>>\", \
\"text\": \"<<parameters.message>>\", \
\"mrkdwn\": true, \
\"color\": \"#1cbf43\", \
} \
] \
}" <<parameters.webhook_url>>
So if I publish this Orb as say sirn/slack@dev, anyone can use this Orb in their build pipeline with: orbs:
slack_notify: sirn/slack@dev
workflow:
foo:
jobs:
- slack/notify:
webhook_url: "..."
message: "..."
I've been using Orb for the past month and I see Orb as a more of a way to share common steps definition (à la Ansible Galaxy) than something of Apt/Brew/NixPkg caliber. It's convenient in CircleCI's context, and easier to get started than trying to build a shared Jenkins Pipeline Scripts, but it's still weird that we're programming in YAML leveraging shell scripts instead of going directly to shell script (which is part of why I love builds.sr.ht).If this is all Docker containers anyway, why aren't they just creating Docker images and referencing them? They're just shoving a Dockerfile into YAML, without the benefit of it actually being a Dockerfile.
I recently migrated a javascript project to typescript. We had some yaml based localization file and I decided to turn it into a typescript file by translating the yaml into json and then turning that into a ts file that exports constants. Crucially, typescript can do type inference and multiline strings.
The benefits of this are that I can now autocomplete keys in the file elsewhere in my code and get their type inferred correctly.
Similarly, gradle now supports kotlin in addition to groovy as a language for specifying build files in. The gradle dsl is more or less a declarative DSL. Using a statically compiled language such as Kotlin means you gain type safety and better tool support (autocomplete, correctness checking). Relative to Groovy you don't actually lose anything in terms of expressiveness but you gain a lot.
Neither typescript nor Kotlin are particularly more verbose than JSON though the lack of supporting a colon to map keys to values in a dictionary remains an unfortunate language choice in Kotlin.
Probably typesafe configuration DSLs are going to be a thing in the future. Neither JSON nor Yaml really do this. And schemas just add a lot of cruft.
You kind of need schemas. Or you need better type systems. I want at least regexp validation, interval validation, etc. from my configuration files.
I rather have my json, but preferably XML with schema validation, having the joy of auto-complete and proper documentation.