resolve buster config from external tool ?

[Magnus Rundberget]

Hi !

I'm working on adding a feature to gradle-buster-plugin that needs information from buster-configuration.

Gradle has support for incremental tasks. I wish to add incremental support to my busterTest task.
For a gradle task to be incremental all one have to do is define which inputs (files and properites) the task has and what outputs (files) it produces.

The inputs on my my busterTest (wrapper around buster-test) task is basically the configuration file and all files/globs specified in the configuration file itself.
For now I've just done some naive parsing of the config file, but the flexibility of buster-configuration (which is great) also makes parsing it slightly complicated and more importantly not very future proof for changes. (Extensions, multiple config groups, each with potentially different rootPath, environment specified etc...)

If I had an api to help me resolve which files/globs to monitor given a config file (and optionally config group) that would be super.

Maybe something in the lines of:
$ buster-configuration --resolve -c config/buster.js  or
$ buster-configuration --resolve -c config/buster.js -g "browser unittests"

which returns a json with a format along the lines of:
{
  ["rootPath": ".", "matches": ["test/*.js", "!test/*-integration-test.js"]],
  ["rootPath": "../", "matches": ["lib/*.js"]],
  ...
}

or maybe you have a better suggestion

cheers
Magnus

[August Lilleaas]

An API to programmatically work with buster-configuration outside of Node.js makes sense to me!

Perhaps something unix-y that just resolves all the globs and lists all the files separated by newline makes sense? I'm not opposed to the idea of outputting JSON, but if we can be "unix compatible" and at the same time solve your problem, that would be great.

--
You received this message because you are subscribed to the Google Groups "Buster.JS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to busterjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Magnus Rundberget]

list of files would be equally good, maybe even simpler. Do you want me to create an issue ?

cheers
Magnus

--
You received this message because you are subscribed to a topic in the Google Groups "Buster.JS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/busterjs/SgJ17b3mJcs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to busterjs+u...@googlegroups.com.

[Christian Johansen]

This is a great idea, and would be fairly simple to implement as well. I'd be interesting in taking a stab at it this weekend. A straight list of files will be difficult, because this is a multi-dimensional output (e.g. n groups). We could have various output formats, but JSON is good to encode all the information about groups, such as environments, files, plugins etc.

C

[August Lilleaas]

+1 to UTF-8 encoded JSON.

Seems to me that a plain list of files will also solve the main problem, which is to list all the files that would be touched by a given test run. So if we have this new CLI mirror buster-test, such as our-new-cli --group "wat" --env "node" only the files for the relevant groups would be listed.

So it's up to the user to decide which one to use. I'm sure there are cases where you would actually want to read out the different groups etc, so it makes sense ot support both plan list of files and JSON.