Task Build Tool

repository·main·Indexed 9 days ago

https://github.com/go-task/task

A fast, cross-platform task runner and build tool inspired by Make, designed for modern development workflows. It provides a CLI for automating repetitive tasks and a Go API (v3) featuring an Executor for task processing, a Compiler for variable resolution, and support for remote Taskfiles, shell completions, and dynamic variable caching.

Tokens
42.2K
Snippets
180
Records
226
Agent score
95%

What's inside Task

  1. Overview of Task: The Modern Task Runner

    main

    Task is a fast, cross-platform build tool inspired by Make, designed for modern workflows. It allows you to automate repetitive tasks like code generation, scaffolding, formatting, and linting by chaining commands and setting dependencies.

    Key features include:

    • 30-Second Setup: Single binary download with zero dependencies. It is available via Homebrew, Snapcraft, Scoop, and more.
    • Cross-platform: Run the same Taskfile on Linux, macOS, and Windows without handling platform-specific quirks manually.
    • Smart Caching: Skip unnecessary rebuilds by tracking file changes using either timestamps or content-based tracking.
  2. Overview of Task's Go Package API

    main

    Task is primarily a CLI tool, but it can be used as a Go package to extend its functionality within Go projects.

    Warning: The package API is experimental and subject to breaking changes in minor or patch releases. It is highly recommended to pin the version in your go.mod file.

    Key packages include:

    • github.com/go-task/task/v3: The core package, primarily used via the task.Executor to fetch and execute tasks.
    • github.com/go-task/task/v3/taskfile: Utilities for reading Taskfiles from various sources (local, HTTP, Git, or stdin).
    • github.com/go-task/task/v3/taskfile/ast: Provides the Abstract Syntax Tree (AST) representation of Taskfile syntax.
    • github.com/go-task/task/v3/errors: Contains error types implementing the errors.TaskError interface, allowing retrieval of unique exit codes via the Code() method.
  3. Understand the Task incident response process

    main

    The Task project follows a five-step incident response plan to handle reported vulnerabilities:

    1. Detect: Security issues are identified via private reports, dependency scanners (e.g., Dependabot), GitHub vulnerability alerts, or community channels.
    2. Triage: Maintainers acknowledge the reporter and categorize the issue by severity (Critical, High, Medium, or Low). A GitHub Security Advisory (GHSA) is opened, and a CVE may be created.
    3. Mitigate: Immediate actions are taken to 'stop the bleed' (e.g., rotating secrets, rebuilding services), followed by addressing the root cause through patching, testing, and releasing new versions.
    4. Disclose: The GHSA is published with details on affected versions, impact, root cause, and resolution steps. Public communication via blogs or social media may follow.
    5. Learn: The incident is documented, and preventative changes are implemented to avoid recurrence.
  4. Understand the Task experiment lifecycle

    main

    Task uses a structured workflow to evolve features from initial ideas to stable defaults. Understanding these stages helps you gauge the stability and risk of using a specific experimental feature:

    1. Proposal: The feature is being discussed via a GitHub issue. No code is available yet.
    2. Draft: Implementation is available in a release. It is open for feedback, but major changes can occur and there are no stability guarantees.
    3. Candidate: The feature is likely to be accepted. It enters a period for final comments and minor changes.
    4. Stable: The functionality is treated as a standard feature. All future changes must be backward compatible.
    5. Released: The feature becomes the default behavior. No flags or configuration are required to use it.

    If an experiment is deemed unsuccessful, it will be marked as Abandoned or Superseded and removed from the project.

  5. Watch files for changes

    main

    Task can automatically re-run tasks when files change using the --watch (-w) flag.

    • Requirement: You must provide a sources attribute so Task knows which files to monitor.
    • Interval: The default interval is 100ms. You can change this globally via interval: '500ms' in the Taskfile root or via the CLI using --interval=500ms.
    • Task-level watch: Setting watch: true inside a task allows it to run in watch mode when called directly from the CLI, but it will not run in watch mode if called as a dependency of another task.
    version: '3'
    
    interval: 500ms
    
    tasks:
      build:
        desc: Builds the Go application
        watch: true
        sources:
          - '**/*.go'
        cmds:
          - go build
  6. Supported Remote Taskfile Node Types

    main

    Task supports three types of remote nodes for referencing Taskfiles:

    1. HTTP/HTTPS: Downloads a file from a specific URL. If the exact filename isn't found, Task will attempt to find a valid Taskfile by appending supported filenames in turn.
    2. Git over HTTP: Downloads from a Git repository using HTTP/HTTPS.
      • Use //<path> to specify the file path within the repo.
      • Use ?ref=<ref> to specify a branch, tag, or commit.
    3. Git over SSH: Downloads from a Git repository using SSH. Requires your SSH agent to have the necessary private keys loaded.
      • Use //<path> to specify the file path within the repo.
      • Use ?ref=<ref> to specify a branch, tag, or commit.
    https://raw.githubusercontent.com/go-task/task/main/website/src/public/Taskfile.yml
    https://github.com/go-task/task.git//website/src/public/Taskfile.yml?ref=main
    git@github.com/go-task/task.git//website/src/public/Taskfile.yml?ref=main
  7. Security: Automatic checksums and trust prompts

    main

    Task implements security checks for remote Taskfiles:

    1. First-time trust: When running a remote Taskfile for the first time, Task prompts you to confirm you trust the source. If you decline, Task exits with code 104 (not trusted).
    2. Checksum changes: Task stores a checksum of the remote file. If the file content changes, Task prompts you to confirm the change. If you decline, Task exits with code 104.

    Handling prompts in non-interactive environments

    If you cannot interact with a terminal, you can:

    • Use the --yes flag to accept all prompts automatically.
    • Use the --trusted-hosts flag to specify specific trusted hosts.
    • Configure remote.trusted-hosts in your taskrc file.
  8. Prevent unnecessary work with fingerprinting

    main

    You can prevent tasks from running if their inputs haven't changed by using sources and generates. Task compares the checksum of the files listed in sources against the files in generates. If they match, Task prints Task "<task_name>" is up to date and skips execution.

    • sources: Files or glob patterns that the task depends on.
    • generates: Files or glob patterns produced by the task.
    • exclude: Used within sources to negate specific files. It must follow the positive glob it is negating.
    • method: Defines how to check for changes. Defaults to checksum. Use timestamp to check modification times instead of content.
    • method: none: Skips validation and always runs the task.
    • use_gitignore: If set to true (at root or task level), Task will exclude files matched by .gitignore from sources and generates resolution.
    version: '3'
    
    tasks:
      js:
        cmds:
          - esbuild --bundle --minify js/index.js > public/bundle.js
        sources:
          - src/js/**/*.js
        generates:
          - public/bundle.js
  9. Understand the Taskfile structure

    main

    Taskfiles are written in YAML and use several key attributes:

    • version: Specifies the minimum version of Task required to run the file.
    • vars: Defines variables that can be accessed within tasks using the {{.VAR_NAME}} syntax.
    • tasks: The core section where individual tasks are defined.
    • desc: A description of the task (used for documentation).
    • cmds: A list of shell commands to execute.
    • silent: A boolean attribute. When set to true, task metadata is not printed, showing only the command output.

    Example Taskfile.yml:

    version: '3'
    
    vars:
      GREETING: Hello, World!
    
    tasks:
      default:
        desc: Print a greeting message
        cmds:
          - echo "{{.GREETING}}"
        silent: true
  10. Use typed variables (booleans, integers, floats, and arrays)

    main

    Starting from version v3.37.0, Task no longer converts all variables to strings. You can now define and use native YAML types including booleans, integers, floats, and arrays. This allows for more natural template logic and enables the use of Sprig math and list functions that require non-string types.

    version: 3
    
    tasks:
      example:
        vars:
          BOOL: true
          INT: 10
          FLOAT: 3.14
          ARRAY: [1, 2, 3]
        cmds:
          - 'echo {{.INT}}'
  11. Access experimental features via feature flags

    main
    To prevent breaking changes from affecting all users, Task introduces 'experimental features' into minor versions. These features are not enabled by default. To use them, you must opt-in by enabling specific feature flags. This allows you to test new functionality and provide feedback before it becomes the default behavior in a future major release.