News for hackers. Stuff that matters.
Re:Show HN: Keep – GitHub Actions for your monitoring tools by xctr94 on Tuesday September 05, 2023 @03:16AM (#37388807)
The complaint doesn’t seem to be about GitHub Actions, but YAML. I agree 100% percent, as soon as I saw that Keep is using YAML, I closed the tab.

Nope. Nope. Nope.

It’s like going back to Mongo without schemas and relational checks. We have perfectly good configuration languages with schemas, checks, imports, logic, etc. YAML is unacceptable in this profession.

Re:Show HN: Keep – GitHub Actions for your monitoring tools by shahargl on Tuesday September 05, 2023 @03:19AM (#37388832)
I agree with you on that as well. The YAML aspect is somewhat of a 'low-level' concern that you shouldn't have to worry about unless you need something highly customized.

Now, let me reverse the question—what would make you keep the tab open?"

Re:Show HN: Keep – GitHub Actions for your monitoring tools by SOLAR_FIELDS on Tuesday September 05, 2023 @07:25AM (#37390293)
“Need[ing] something highly customized” is not some uncommon occurrence for your end users. It’s an inevitability for a large portion of them.

Give me some well supported libraries in common general purpose languages to do this, codegen is pretty good these days and supporting 3 or 4 languages shouldn’t be an insurmountable achievement.

Re:Show HN: Keep – GitHub Actions for your monitoring tools by shahargl on Tuesday September 05, 2023 @07:42AM (#37390406)
got you, so you would imagine some typescript/python/golang sdk that let you define workflows?
Re:Show HN: Keep – GitHub Actions for your monitoring tools by SOLAR_FIELDS on Tuesday September 05, 2023 @07:52AM (#37390484)
Precisely. Let me interweave that into my implementation as I see fit. Maybe for some people that’s just literally pasting an example into GitHub actions and saying “python keep.py myargs” but it doesn’t have to be, it’s just another tool chain in the general purpose environment
Re:Show HN: Keep – GitHub Actions for your monitoring tools by shahargl on Tuesday September 05, 2023 @08:25AM (#37390718)
will definitely have it in mind, thanks for the input. btw any other tools do you know that doing it?
Re:Show HN: Keep – GitHub Actions for your monitoring tools by phinnaeus on Tuesday September 05, 2023 @08:32AM (#37390790)
AWS CDK has bindings for a few languages
Re:Show HN: Keep – GitHub Actions for your monitoring tools by lijok on Tuesday September 05, 2023 @04:43AM (#37389321)
Could you point to the mentioned configuration languages with schemas, checks, imports, logic etc?
Re:Show HN: Keep – GitHub Actions for your monitoring tools by thinkmassive on Tuesday September 05, 2023 @05:46AM (#37389742)
Re:Show HN: Keep – GitHub Actions for your monitoring tools by lijok on Tuesday September 05, 2023 @06:03AM (#37389837)
These are interesting. I've seen both before but never understood - if I have a config that cannot be easily written out in yml, why would I force my team to learn either one of these DSLs instead of using our main dev language (say python) to generate the yml instead? What's the value proposition of jsonnet or cue?
Re:Show HN: Keep – GitHub Actions for your monitoring tools by SOLAR_FIELDS on Tuesday September 05, 2023 @07:13AM (#37390229)
One very important thing to point out here is that you’re not just writing config with this YML. If you look at the example on the GitHub link it’s a workflow orchestration and execution context. There’s a code runtime involved and logic is executed in the YAML. That is where YAML falls apart.

If all you’re doing is defining configurations (example is Kubernetes manifests helm charts etc) then great. But that isn’t what this is.

To your original question, I would actually advocate using the general purpose programming language for most use cases. Learning a new DSL, like you mentioned, is overhead from both a usability and maintainability perspective. I haven’t used jsonnet before but I know that cuelang gives you some power tools around typing, config validation, templating etc. it’s essentially purpose made for configuration management and tooling so it’s probably going to be really good at that. I don’t know if it’s worth using over a suite of language specific tools like Pydantic + Jinja though because when you’re using a general purpose language like python you have a whole, much larger ecosystem of tools and libraries you also have access to and can pull from.

Re:Show HN: Keep – GitHub Actions for your monitoring tools by thinkmassive on Tuesday September 05, 2023 @07:02PM (#37399004)
I agree with this for internal tools only intended to be used by a relatively small organization. Using a DSL may well be preferable for open source, and for larger organizations where not every team is proficient in your Turing-complete language of choice.

Some drawbacks of plain YAML, and of tools that use string templating to render YAML:

    - difficult to extend features not exposed by upstream
    - composition is often messy, resulting in duplication
    - validation is often impractical (at least identifying the exact source of the error… I’m looking at you Helm!)
Unrelated to OP, but you can leverage Tanka to extend helm charts with functionality not provided by upstream.

https://tanka.dev/