Enforce all configuration in gitted YAML directory

[haraldrudell]

• There is value in Strider-CD because it is Node.js based and therefore can be installed and launched with a one-liner
• Continuous deployment, however, requires EVERYTHING to be under revision control
• The de-facto standard format for configuration has become YAML 1.2 (js-yaml)
• Therefore, a single directory should be used for all configuration, including installed plugins and their configuration, a directory that can be gitted, to avoid the traditional Jenkins uncloneable snowflake
• This way there is traceability and a Strider-CD instance can be cloned using npm install and git pull
• The database is allowed to contain history

And then:

• Write all code from now on using ECMAScript 2016 with stage-3 async/await and babel
• Allthough features of Strider-CD are presently basically broken, it can be made to run at the cost of security, which is somewhat OK on localhost

[knownasilya]

All configuration can currently be setup in a strider.json file. See https://github.com/Strider-CD/strider/wiki/Advanced-Configuration. There is also an issue for supporting yaml or json5 instead of just json here #960

[oliversalzburg]

I am strictly against using any transpilers for backend code. It makes it extremely hard to debug and has very little benefit compared to its cost. We have literally just dropped Node <4 support and thus brought a bunch of new ES features into the code base.

[haraldrudell]

Point taken.

• The situation with modern code is somewhat complex at the moment, if you don't use babel, you can't say import, so if you want ECMAScript 2015, in practice you must use babel.
• If you do use babel, and a bit of a setup with in this case webpack and source maps, you can debug like you are on the modern code base with instant hot reload of both front-end and server, not knowing that there is transpiling taking place. What you cannot get is proper line numbers in stack traces.
• There are many reasons for using at least ECMAScript 2015, which was a large release, but for devOps and Continuous Deployment work, async functions enabling branching promises produces procedural-looking yet event-driven code with good error handling. The error handling featured is hard to attain with callback/emitter programming.
• Have a look at build.js from React Starter Kit. The wrapper run.js is able to log start and completion events nicely.

It's an idea.

[knownasilya]

I'm also looking forward to async/await, but in the mean time we can use generators with Node 4+ which is made even nicer with https://github.com/kamikat/co-router. And yes, the error handling is much improved with this router, because ALL errors go to the error handler middleware, no need to catch/try on every route.

Which I'll probably start using when I continue cleaning up and documenting the routes.

[haraldrudell]

I also looked further into YAML and was surprised to see that Amazon AWS does not support it yet, they are still on JSON. There are many npm modules converting between JSON and YAML, but Linux does not come with a pre-installed utility for the conversion.

Linux does have Python 2.7, though, for the AWS command line. You can find tool-deprived people pleading with Amazon to implement YAML. The SaltStack and ansible both use Python with Jinja/YAML configuration file format.

JSON to YAML

aws ec2 run-instances --generate-cli-skeleton | python -c 'import sys,yaml,json;yaml.safe_dump(json.load(sys.stdin),sys.stdout,default_flow_style=False)'

YAML to JSON

cat i.yaml | python -c 'import sys,yaml,json;json.dump(yaml.load(sys.stdin),sys.stdout)'

[knownasilya]

YAML for us isn't a high priority, because it's not really a standard, just some people prefer it. We are more concerned about all of the configuration being possible somehow without the UI and having it be replicated/updated easily in a vcs.

Having said that, we would take a PR for supporting strider.yml along side of strider.json (backwards compatible). We might even talk about changing to .strider.yml to be more like Travis (without the backwards compatible support), but this would only be in a major release (with the Node4 change).

[oliversalzburg]

If you want to go transpiling on the frontend code, go bananas for all I care. As long as someone is working on it, it's probably being improved. For all I care, rewrite it in React from scratch.

With backend code, it's not just wrong line numbers in stack traces, it's simply debugging the code (as in attaching the node debugger). And, yeah, I know there is babel-node, but that doesn't work with whatever IDE. It needlessly overcomplicates the development process. As I said earlier, we literally dropped support for Node <4.2 days ago. Let's work with what is natively supported.

That being said, I would welcome a .strider.yml contribution, just because it will make it easier to approach for people coming from other CI solutions.

[haraldrudell]

And hey, @oliversalzburg

I noticed too, some front-end projects so uninterested in server debugging that they "forgot" to have a setting --debug for the server

What I did then was put Node.js into debug, likeso, enabling you to attach any debugger to the running back-end:

if (o.debug) process.kill(process.pid, 'SIGUSR1') // enable debugging for this process
console.log(`pid: ${process.pid}`)