travis-ci/travis-core — pull request #363 by drogus (2014-03-13 16:09:34+00:00)
Title: [WIP][sanity check needed] Config validator

A while ago I started preparing a simple config validator which would allow us to reject requests if the config is malformed (like: a user puts an array instead of hash or something like that).

The idea is to have a simple DSL which would allow us to specify what's allowed and what's not, like:

```ruby
entry :env, type: [:string, :array, :hash] do
entry :global, type: [:string, :array] do
values for: :array, only: [:string, :hash]
end
entry :matrix, type: [:string, :array] do
values for: :array, only: [:string, :hash]
end

values for: :array, only: [:string]
end
```

As @roidrage is trying to get rid of various small errors, I think this would greatly simplify things, because we would not have to worry about malformed values in config. With requests API in place it will be also easier to communicate a problem to the user. I was reluctant to work more on config validator in the past, because without a way to see why builds are not showing up, it would create a really poor experience.

Another possible way to handle that is to "objectify" the config, so instead of handling everything as yml/json:

```ruby
if config[:env] && config[:env][:something] && config[:env][:something][:something_else]
```

we could do something like:

```ruby
config.env #=> Build::Config::Env instance
config.env.global #=> ["FOO=bar"]
config.env.matrix #=> ["BAR=baz"]
```

What do you think about that? Should I continue with config validator as a DSL, or do you think that creating a definitions for parts of config would be a better approach?