What is the deal with strider.json?

[oliversalzburg]

While looking into other issues, I found a log message telling me Strider config is invalid JSON for.... And the logged contents are { message: '404 File Not Found' }.

I have no strider.json anywhere, so what is going on here?

[knownasilya]

Are you using the latest version of Strider and all plugins updated?

[oliversalzburg]

@knownasilya I think so, this is happening on the instance I was messing with yesterday.

My assumptions is, that this is a mechanism that allows me to modify the strider configuration through a file placed into the repository, but I wanted to make sure and I think the process could be made more clear if my assumptions is valid.

[knownasilya]

It's documented here: https://github.com/Strider-CD/strider-custom#using-striderjson
but I think the implementation is either in strider itself, or one of the runner libs.

[oliversalzburg]

@knownasilya Hah! Perfect. That is exactly what I was trying to do for our projects right now :D I'll take it for a spin right away.

[oliversalzburg]

@knownasilya I would appreciate some help, because this isn't working at all.

The strider.json is retrieved and merged a branch configuration retrieved through mongoose. Which makes sense, as the strider.json should be able to affect all of the configuration items.

But then, later, the runner will never pass the whole configuration to the plugins, only their specific configuration.

And you can't target a plugin by name in strider.json, because the plugins are just in an ordered array.

How is this supposed to work?

[oliversalzburg]

Okay, I think, I have a working version now:

{
    "merge_plugins": true,
    "plugins": [
        {
            "id": "custom",
            "prepare": ".scripts/prepare.sh",
            "deploy": ".scripts/deploy.sh"
        }
    ]
}

You need the merge_plugins member to have mergeConfigs invoke mergePlugins, so that it even looks at plugin configurations at all.

The latter then expects plugins to be an array, where each element has an id member with the name of the plugin. That element then replaces the complete configuration of the plugin.

Unless I'm missing something, this doesn't seem like an intuitive approach.

You should just be able to address plugins by name and the given configuration should be merged, just like the rest of the configuration items from strider.json are merged.

[oliversalzburg]

Also, the mergePlugins code mentions strict_plugins, which apparently controls above mentioned behavior. But the flag is nowhere to be found and is actually never taken into account.

[oliversalzburg]

Okay, so, now I have a fully working strider.json for controlling plugins:

{
    "merge_plugins": true,
    "plugins": [
        {
            "id": "custom",
            "enabled": true,
            "showStatus": true,
            "config": {
                "prepare": ".scripts/prepare.sh",
                "deploy": ".scripts/deploy.sh"
            }
        }
    ]
}

I still think plugin configs should be merged, not replaced. This feature seems incredibly useful to me, but I feel like it's impossible for a non-developer to get.

[knownasilya]

I didn't know that this was even possible! Nice!

[oliversalzburg]

@knownasilya Actually, the complete configuration for the branch can be overridden. Now that I finally have a grasp on it, it's just awesome. Needs to be documented better IMHO though.

[knownasilya]

@oliversalzburg maybe start something up in the wiki, and flesh it out as you know more.

[oliversalzburg]

@knownasilya Will do!

If you have an opinion regarding how the strider.json should be treated in combination with the settings in the web UI, I'd love to hear it.

[knownasilya]

Since it's a power tool, I personally think it should override the web-ui configuration (at least for the options that you specify), otherwise it gets too complicated and hard to reason about. Also hard to explain how to configure it.

[niallo]

yes that was exactly the point - you could override specific settings if
you wanted.

I am unsure that the order makes sense though. perhaps it is better for the
web ui to override strider.json.

On Wednesday, June 3, 2015, Ilya Radchenko notifications@github.com wrote:

Since it's a power tool, I personally think it should override the web-ui
configuration (at least for the options that you specify), otherwise it
gets to complicated and hard to reason about. Also hard to explain how to
configure it.

—
Reply to this email directly or view it on GitHub
#789 (comment).

Niall O'Higgins
W: http://niallohiggins.com
E: n@niallo.me
T: @niallohiggins

[oliversalzburg]

@niallo The current implementation seems to be that the strider.json overrides the web config. It only got complicated once I got to the plugin configurations, where the order matters.

For simplicity, let's assume I have 2 plugins, but their order is reversed between the web-ui and strider.json. Which order is the one to use? And once you pick the order, which plugin configuration overrides which?

And, to take it further, what happens if a plugin configuration only exists on one side? Is it inserted at the top or the end of the chain in the final config?

[knownasilya]

Plugin configuration should override as a whole.

[oliversalzburg]

@knownasilya So, that would mean dropping the merge_plugins flag/behavior? That would definitely make things easier.

[knownasilya]

Exactly