Mimic Migration Module Drush Commands More Closely

Off-hand, the migration flags are:

--limit=
--idlist=
--migrate-debug (If this flag is set, pass it into the migrate:import command we call with code).
--group: migrate by group
--tag: migrate by tag
--all : run all migrations

just nice to haves (imo):
--feedback=FEEDBACK <-- progress messages In migrate, it is a means of saying often to provide progress feedback, but it could also just be a on/off flag for this module
--skip-progress-bar

In places where these options would also be applicable to the queue command it might be nice to harmonize the interface between orange-dam:queue* command and orange-dam:migrate* commands, all based off of some of these options and formatting conventions.

@apotek that is helpful, thank you!

@apotek I believe the changes I made address the needs you surfaced. It should pass through any options that are sent to it.

I have tested the options with the migration-run command and they work.

I added some suggestions to the merge request, asked a further question there, and also am wondering if we want to change the way the migration name is invoked. Currently, orange_dam drush commands specify the migration with an `--migration` option. But the migrate module specifies it as a bare argument. IOW, we do `drush orange-dam:migration-run --migration=` but the migrate module does it this way `drush migrate:import `

Should that also be changed as part of this request or is this outside the scope for the feature request. The feature request does ask to match the migrate CLI api, so I don't feel it is out of scope. However, for pragmatic reasons, if hard to implement, we might want to defer that part of the change.

Currently, orange_dam drush commands specify the migration with an `--migration` option. But the migrate module specifies it as a bare argument. IOW, we do `drush orange-dam:migration-run --migration=` but the migrate module does it this way `drush migrate:import `

@apotek I actually tried to go down that road and if we go that route, we will lose the ability to not pass a migration and have the interaction choice tool. So I can see both sides of the argument. What are your thoughts?

Cannot add a required argument after an optional one.

I'm going to merge the changes we have so far, and we can continue the discussion about this.

I think the thing to do here is to close this as fixed and we'll open more targeted requests for where specific options are misaligned and where that causes the most friction. This was a win, but not complete. But completing it can't be a top priority now, and we should close this as an improvement that is good enough that we can later iterate over.

Automatically closed - issue fixed for 2 weeks with no activity.