-
Notifications
You must be signed in to change notification settings - Fork 373
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
Pipeline execution order #2410
Labels
Comments
Alternate names and including an API: public enum CliPipelinePhases
{
// I am actually not sure we need this, as ValueSubsystem needs to act like it is executing to get its data
NonExecuting = 0,
/// <summary>Operations that do not require data prep and that generally supersede invocation.</summary>
EarlyTermination, // NonData?
/// <summary>Operations that work with data prior to invocation, such as validation. These can terminate on error.</summary>
DataPreparation, // ValuePreperation?, BeforeInvocation?
/// <summary>Invoking operations</summary
Invocation,
/// <summary>Error reporting, ExitCode transposition, possibly exception handling, cleanup</summary
Finishing
}
public class Pipeline
{
//...
public void AddSubsystem(CliSubSystem subsystem, CliPipelinePhase phase, bool atStart = false) {...}
//...
} The pipeline would also continue to have properties for the expected subsystems, such as Help that could be used to replace the default, so this would not be the common case. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have taken or considered many approaches to pipeline ordering. What we have observed:
The groupings are these:
Relavent design decisions
dotnet new
in the .NET CLI). We anticipate these CLI authors will create an aggregating subsystem and route.Proposal
Create pipeline groups with great names for:
EarlyTerminating
BeforeInvocation
Invocation
AfterInvocation
NonExecuting
Hey, are those great names?
New subsystems would be placed in a group:
We think it will rarely matter whether something runs first or last within its group. It would only matter when the new subsystem alters the behavior of another subsystem. To allow further customization within the group, we can commit to retaining the order things were added at eitehr the first or last position in the group. There will be only obtuse (*) ability to change the order of standard subsystems.
(*) We can't keep someone from removing it at its normal position and placing it elsewhere. That seems pathological.
Other approaches considered
main
. It's complicated.)ExecuteHelp
(weird and complicated).The text was updated successfully, but these errors were encountered: