Parent Incremental Build Tasks should skip dependent tasks

[Justin Grote]

Reproduce

task ChildTask @{
    Inputs={
        Write-Host "INPUTS: This should not run because ParentTask should have skipped the child tasks"
        'FileThatDoesntChange.txt'
    }
    Outputs={
        Write-Host "OUTPUTS: This should not run because ParentTask should have skipped the child tasks"
        'ChildTaskOutput.txt'
    }
    Jobs= {
        Write-Host -Fore Green 'Running Child Task!'
        'Written!' > ChildTaskOutput.txt
    }
}

task ParentTask @{
    Inputs = {
        Write-Host 'PARENTINPUT: Never runs'
        'FileThatDoesntChange.txt'
    }
    Outputs = {
        Write-Host 'PARENTOUTPUT: Never runs'
        'ChildTaskOutput.txt'
    }
    Jobs = 'ChildTask'
}

task . ParentTask

Expected

The ParentTask Input/Output would evaluate and not run the child jobs

Actually

The ParentTask Input/Output evaluation is completely ignored

Workaround

Define the Input/Outputs as a variable and assign them to every child task. Not ideal due to being redundant

[Roman Kuzmin]

@JustinGrote This is by design and documented, at least here: How-Build-Works.

(4) Before the first script block is invoked, the inputs and outputs from the parameters Inputs and Outputs are evaluated and compared. If they are not specified or outputs are out-of-date then all script blocks are invoked. Otherwise script blocks are skipped, only referenced tasks are invoked.

IIRC, MSBuild works in the same way. MSBuild was the source of decisions on doubts.

This way may look unusual but this depends on how you look at what a task is. Referenced tasks must be invoked (it's up to them to skip or not), own jobs - maybe, depending on incremental conditions. A task is responsible for its own jobs not others.

[Justin Grote]

OK, so basically any "summary" tasks (e.g. Build comprised of sub tasks copy modules, update version ,etc.) should never have inputs or outputs assigned to "rollup skip" tasks.

This is tricky with loosely coupled tasks as well as incorporating clean, but I'll make it work, thanks for the clarification.

[Roman Kuzmin]

This behaviour has some advantages if you think of it more. You can effectively count on referenced tasks invoked, no matter what incremental state is. In particular this makes visual build graphs easier to treat, edges connecting task nodes mean "invoke", not "maybe invoke".

[Justin Grote]

@nightroman absolutely I understand the intent and ideal, I just have to restructure things a bit to accomidate. Thanks for all the hard work on such a great module!