Skip to content

How do I access the command-line args in a task? #175

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sethladd opened this issue Apr 14, 2015 · 12 comments
Open

How do I access the command-line args in a task? #175

sethladd opened this issue Apr 14, 2015 · 12 comments
Labels

Comments

@sethladd
Copy link
Collaborator

context doesn't seem to have it.

use case: I want to run something like grind bumpversion minor or grind bumpversion plus and automate the steps to bump a version

@seaneagan
Copy link
Contributor

The top-level grinderArgs() is intended to expose those, but I'm pretty sure if you pass in any positional args, options, or flags that grinder doesn't understand, grinder's arg parsing will currently fail anyways. The issue for fixing that is dart-lang/core#46.

@devoncarew
Copy link
Contributor

Do we need to support something like this:

grind foo_task some args bar_task other args

? Or do we just pass all args to the last task mentioned? Or only allow one task to be listed on the command-line if any task args are used?

grind foo_task i get all the --args

@sethladd
Copy link
Collaborator Author

I think this would be confusing, as one task's args could be the name of a task: grind foo_task some args bar_task other args

@sethladd
Copy link
Collaborator Author

What do other systems do?

@seaneagan
Copy link
Contributor

I think all positional args should be task names, so task args must be --option[=]value or --flag. I think we can allow those options/flags anywhere on the line. dart-lang/core#46 discusses a mechanism to declare and be injected with args they care about (similar to unscripted), interested to get feedback on that.

Grunt allows targets:

grunt deploy:prod

I don't think I like that as much, but it is a way to send args to a single task instead of all who use the same named options.

@seaneagan seaneagan reopened this Apr 16, 2015
@seaneagan
Copy link
Contributor

One thing to note is that you may want to pass an option to a dependency task, which is not even specified on the command line. --option=value and --flag would be the ticket for that.

@sethladd
Copy link
Collaborator Author

target might work for me.

Ultimate I want to do this:

grind version:bump:major

grind version:bump:minor

etc

So I can create a deployment workflow:

  • verify formatting
  • run all the tests
  • bump version
  • push to git
  • push to pub.dartlang.org

@devoncarew devoncarew modified the milestone: 0.7.1 Apr 17, 2015
@devoncarew
Copy link
Contributor

Let's plan on releasing 0.7.0 w/o being gated on this, but following up in an 0.7.1 to address letting tasks have args.

@sethladd
Copy link
Collaborator Author

sgtm.

@sethladd
Copy link
Collaborator Author

Now that 0.7.0 is out, I'd like to re-open. My use case is, I had a single task that wanted to take an argument. The workaround was to create two differently named tasks. In the old syntax:

taskBumpMajor() { bump(major); }

taskBumpMinor() { bump(minor); }

But of course, I can't deal with more than one arg to a task, unless I want an explosion of task names :)

So, I'd like to be able to call a task and somehow pass it args for more specialized behavior, from the command line.

Thanks!

@zoechi
Copy link

zoechi commented Apr 22, 2015

Maybe this could help here too dart-lang/core#107

@devoncarew
Copy link
Contributor

Just anecdotally, I ran into this use case myself this morning. I wanted to pass a single text param to a task: a new milestone version that would be re-written in a few places in the source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants