CLI flag for config file #4

jzaefferer opened this Issue Jul 6, 2012 · 12 comments


None yet

5 participants


Currently I edit a grunt.js file whenever I want to use a different configuration to deploy to staging. I then need to remember to undo that change, and not commiting it with others.

Currently the config file is actually inside each grunt.js file - I wouldn't really want to duplicate the flag thing across all our projects using grunt-wordpress, and there's also the problem of passing arguments from one task to another. We'd probably need a custom task here then updates the configuration before scheduling the deploy task to run.

Maybe @rdworth or @cowboy have some input here as well?

rdworth commented Jul 6, 2012

I don't know what is going to be the right setup as far as grunt or grunt-wordpress, but my ideal would be to be able to do one of something like

grunt deploy
grunt deploy:dev
grunt deploy:stage
grunt deploy:prod

where right now I'm running a script that rewrites the contents of config.json (or I edit it manually) before running grunt deploy

cowboy commented Jul 6, 2012

Well, giving your deploy task an argument would be pretty idiomatic. Maybe it's a multi-task whereby grunt deploy deploys everywhere while grunt deploy:dev deploys to just dev?


What if we modify the config to support named configs:

    dev: { url: "...", ... },
    stage: { url: "...", ... },
    prod: { url: "...", ... },
    _default: "dev",
    dir: "/dist"

If you don't specify a target, it uses whatever _default points to (can support a name or a config object). If _default doesn't exist, then it assumes that the config is flat and doesn't contain named configs.


@cowboy deploy everywhere sounds scary.

rdworth commented Jul 6, 2012

@cowboy deploy everywhere sounds scary.


cowboy commented Jul 6, 2012

Maybe there can be a way to declare a multi task to do everything except the target iteration part, which is the default behavior. Right now, there is absolutely no way of declaring that.


@cowboy There's no reason for this to be a multi-task. You would never want to deploy to multiple sites at once.


Scott's suggestion looks good to me. Keep it as a regular task, with flags to figure out which config to use, and just a single config file.


Looked into actually implementing this. First issue, explaining why Ben mentioned the multi-task:

Calling grunt deploy:stage fails with <WARN> Task "stage" not found. Use --force to continue. </WARN>. Looks like non-multi-tasks can't have those flags, at least in grunt 0.3.11?

Even if that gets resolved, the next problem: deploy is an alias for wordpress-deploy, which is an alias for build-wordpress wordpress-publish and so on. And the location where we'd actually need that flag is a helper, not a task:

With that in mind, I wonder if we should also tackle this with env variables, as in

grunt deploy
target=dev grunt deploy
target=stage grunt deploy
target=prod grunt deploy

Or, with that grunt-jquery-content issue resolved:

target=dev nohighlight=true grunt deploy

cowboy commented Jul 12, 2012

FWIW, this may be of help cowboy/grunt#277. Just a few ideas that may or may not be useful in the long run.

@cowboy cowboy referenced this issue in jquery/grunt-jquery-content Jul 12, 2012

Option to disable code highlighting #3

@jzaefferer jzaefferer added a commit to jzaefferer/grunt-wordpress that referenced this issue Jul 12, 2012
@jzaefferer jzaefferer Implement a target task to specify deployment targets. Update wordpre…
…ss-client helper accordingly. Fixes #4 - CLI flag for config file

See #6

@scottgonzalez scottgonzalez added a commit that closed this issue Jul 18, 2012
@jzaefferer @scottgonzalez jzaefferer + Implement a target task to specify deployment targets. Update wordpre…
…ss-client helper accordingly. Fixes #4 - CLI flag for config file
jwbeech commented Dec 14, 2012

Guys you can use the follwoing when you run your build:
$grunt --<propertyName>=<configFilePath>

Then in your script you can retrieve that property by using:

Any external properties you like.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment