Add posix and bash opts for status and precondition commands.

[trulede]

set/shopts are applied to cmd variants:

• status
• precondition
• if
• sh both status and precondition commands

fixes #2469
fixes #1901

[Copilot]

Pull request overview

This PR aims to ensure Taskfile set: (POSIX set -o) and shopt: (bash shopt -s) options are consistently applied beyond cmd/cmds, specifically to status, precondition, and if command execution paths, addressing issues where pipefail/other opts were previously ignored.

Changes:

• Plumb POSIX/Bash opts into execext.RunCommand calls for task/command if conditions and task preconditions.
• Extend fingerprint status checking to accept and apply POSIX/Bash opts when running status commands.
• Thread POSIX/Bash opts into dynamic env var (env:) sh: evaluation during task compilation.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
variables.go	Passes effective set/shopt options into dynamic env: sh: evaluation during compilation.
task.go	Applies set/shopt to task-level and command-level if: checks; passes opts into fingerprint status evaluation.
status.go	Passes Taskfile-level set/shopt into fingerprint status evaluation.
precondition.go	Applies set/shopt to preconditions[].sh execution.
internal/fingerprint/task.go	Adds functional options to carry POSIX/Bash opts into the default status checker.
internal/fingerprint/status.go	Runs status: commands with merged POSIX/Bash opts.
compiler.go	Extends dynamic var evaluation API to accept POSIX/Bash opts (but currently supplies empty opts from getVariables).

Comments suppressed due to low confidence (1)

task.go:176

• If conditions now receive PosixOpts/BashOpts, but there are no tests asserting that set: options (notably pipefail) change if: evaluation/skip behavior. Consider adding coverage for task-level if: and command-level if: with a failing pipeline to ensure the opts are actually applied and remain so.

	if strings.TrimSpace(t.If) != "" {
		if err := execext.RunCommand(ctx, &execext.RunCommandOptions{
			Command:   t.If,
			Dir:       t.Dir,
			Env:       env.Get(t),
			PosixOpts: slicesext.UniqueJoin(e.Taskfile.Set, t.Set),
			BashOpts:  slicesext.UniqueJoin(e.Taskfile.Shopt, t.Shopt),
		}); err != nil {
			e.Logger.VerboseOutf(logger.Yellow, "task: if condition not met - skipped: %q\n", call.Task)
			return nil
		}
	}

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[vmaerten]

Hey Thanks for working on it.
I think we can avoid passing opts everywhere by merging them earlier, in compiledTask:

  // variables.go
  Set:   slicesext.UniqueJoin(e.Taskfile.Set, origTask.Set),
  Shopt: slicesext.UniqueJoin(e.Taskfile.Shopt, origTask.Shopt),

Since compiledTask always runs before status checks, preconditions, if, etc., the compiled task already carries the merged opts and all the call just do PosixOpts: t.Set with no extra plumbing. StatusChecker loses its stored fields, WithPosixOpts/WithBashOpts go away, HandleDynamicVar keeps its original signature

What do you think ?
Also it may worth it to add a test for this :)

[trulede]

@vmaerten I took your suggestion, but it did not help much with HandleDynamicVar as that function does not have access to the task owning the variable. However, that function is called from only two places ... both have a task variable (of some kind), so its probably possible to change the signature to include the relevant task.

A bigger question is if the existing approach was actually correct. Consider this:

err = execext.RunCommand(ctx, &execext.RunCommandOptions{
    ...
    PosixOpts: slicesext.UniqueJoin(e.Taskfile.Set, t.Set, cmd.Set),
    BashOpts:  slicesext.UniqueJoin(e.Taskfile.Shopt, t.Shopt, cmd.Shopt),
})

Should these options be a set/merge of all provided options (taskfile, task, cmd)? Or, should it be an overriding selection, so use cmd.opts if defined, else use task.opts if defined, else use taskfile.opts.

I think the latter is more correct, since it makes it possible to disable an earlier/lower setting. For example:

-- Taskfile.yml --
version: '3'

set: [pipefail]

tasks:
  default:
    cmds:
      - task: global
      - task: task
      - task: command
  global: echo **/*.go 
  task:
    set: []  # ***** Disable pipefail
    cmds:
      - cmd: echo **/*.go
  command:
    set: [hashall]  # ***** Replace pipefail with hashall
    cmds:
      - cmd: echo **/*.go
        set: [pipefail hashall]   # ***** Replace hashall with hashall and pipefail