5 ms·
Alternatively, if you're programming and you want a structured data format, use S-expressions! They are basically tailor-made for exactly this problem. (g
by zeveb 8y ago
Alternatively, if you're programming and you want a structured data format, use S-expressions! They are basically tailor-made for exactly this problem.
(gitlab:assets:compile
#%dedicate-no-docs-pull-cache-job
(image "dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.5.3-git-2.18-chrome-71.0-node-8.x-yarn-1.12-graphicsmagick-1.3.29-docker-18.06.1")
(dependencies
setup-test-env)
(services
(docker stable-dind))
(variables
(NODE_ENV production)
(RAILS_ENV production)
(SETUP_DB false)
(SKIP_STORAGE_VALIDATION true)
(WEBPACK_REPORT true)
;; we override the max_old_space_size to prevent OOM errors
(NODE_OPTIONS "--max_old_space_size=3584")
(DOCKER_DRIVER overlay2)
(DOCKER_HOST "tcp://docker:2375"))
(script
"node --version"
"yarn install --frozen-lockfile --production --cache-folder .yarn-cache"
"free -m"
"bundle exec rake gitlab:assets:compile"
"time scripts/build_assets_image"
"scripts/clean-old-cached-assets")
(artifacts
(webpack-report
(expire-in 31d)
(paths
"webpack-report"
"public/assets/"))))
And that’s just a first cut; it could be made much nicer.
- lmm 8y ago> And that’s just a first cut; it could be made much nicer. This is exactly the problem with S-expressions. No-one is willing to define what "good enough" looks like and create a fixed, reusable standard for how you represent these things. Instead everyone hand-rolls their own, subtly incompatible variant.
- taeric 8y agoWhatever is the final evaluator gets to define what is required. Beyond that, give your users the power to do it their way. Or they will find a way to get it themselves.
- lmm 8y ago> Whatever is the final evaluator gets to define what is required. Which is completely useless, because it means everyone will do it differently. > Beyond that, give your users the power to do it their way. Or they will find a way to get it themselves. Users put value on having a standard set of scaffolding. That's why these standardised config formats have succeeded.
- taeric 8y agoHave you seen the plethora of templating engines used to generate the yaml configs out there? I am surrounded by folks that think Jinja to create yaml is a normal idea. Good, even. Then there is the slow creep of Turing into config for the sake of dynamic config. Starts as a simple condition flag. Then add if/then logic. It is an amusing tread. So, yes. You can get a lot of variety in how configs look. But at the end if the day, they should all work. Usually in much more explainable terms. Just look at most people's emacs config. There are good options to make those readable today. It is still not that hard to see how most people's have worked for a long time.
- lmm 8y agoAre those options agreed on and used consistently though? Other people's emacs configs are even more notoriously unreadable than Jinja-templated yaml, IME.
- taeric 8y agoI've found emacs configs are actually not that bad, all told. There can be a lot there, and some are certainly more organized than others, but just figuring out what is happening is usually not hard. Reading people's CloudFormation and related templates? Especially if they are done using jinja or some other yaml generation trick? Near impossible. To directly answer your question, though. No, it does not appear that anyone agrees on how to generate config for things. Which is why every team I join seems to have invented a new way for doing it, all in the name of "maintainability." I often get dirty looks for suggesting that people not build automation on top of the config before they have proven it is truly needed with experience. (That is, if this is your first config to create, do it by hand for the reviewability, if for no other reason.)
- ezrast 8y agoOkay, you've re-serialized the data structure in a slightly different format. Is there a step 2 I'm not seeing?