Task Build Tool
repository·main·Indexed 9 days ago
https://github.com/go-task/taskA 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.
What's inside Task
- Task is a fast, cross-platform build tool inspired by Make, designed for modern workflows. It serves as a modern task runner to automate repetitive development tasks.
Overview of Task: The Modern Task Runner
mainTask 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
Taskfileon 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.
Overview of Task's Go Package API
mainTask 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.modfile.Key packages include:
github.com/go-task/task/v3: The core package, primarily used via thetask.Executorto 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 theerrors.TaskErrorinterface, allowing retrieval of unique exit codes via theCode()method.
Understand the Task incident response process
mainThe Task project follows a five-step incident response plan to handle reported vulnerabilities:
- Detect: Security issues are identified via private reports, dependency scanners (e.g., Dependabot), GitHub vulnerability alerts, or community channels.
- 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.
- 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.
- 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.
- Learn: The incident is documented, and preventative changes are implemented to avoid recurrence.
Understand the Task experiment lifecycle
mainTask 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:
- Proposal: The feature is being discussed via a GitHub issue. No code is available yet.
- Draft: Implementation is available in a release. It is open for feedback, but major changes can occur and there are no stability guarantees.
- Candidate: The feature is likely to be accepted. It enters a period for final comments and minor changes.
- Stable: The functionality is treated as a standard feature. All future changes must be backward compatible.
- 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.
Watch files for changes
mainTask can automatically re-run tasks when files change using the
--watch(-w) flag.- Requirement: You must provide a
sourcesattribute 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: trueinside 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- Requirement: You must provide a
Supported Remote Taskfile Node Types
mainTask supports three types of remote nodes for referencing Taskfiles:
- 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.
- 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.
- Use
- 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.
- Use
https://raw.githubusercontent.com/go-task/task/main/website/src/public/Taskfile.ymlhttps://github.com/go-task/task.git//website/src/public/Taskfile.yml?ref=maingit@github.com/go-task/task.git//website/src/public/Taskfile.yml?ref=mainSecurity: Automatic checksums and trust prompts
mainTask implements security checks for remote Taskfiles:
- 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). - 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
--yesflag to accept all prompts automatically. - Use the
--trusted-hostsflag to specify specific trusted hosts. - Configure
remote.trusted-hostsin yourtaskrcfile.
- 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
Prevent unnecessary work with fingerprinting
mainYou can prevent tasks from running if their inputs haven't changed by using
sourcesandgenerates. Task compares the checksum of the files listed insourcesagainst the files ingenerates. If they match, Task printsTask "<task_name>" is up to dateand skips execution.sources: Files or glob patterns that the task depends on.generates: Files or glob patterns produced by the task.exclude: Used withinsourcesto negate specific files. It must follow the positive glob it is negating.method: Defines how to check for changes. Defaults tochecksum. Usetimestampto check modification times instead of content.method: none: Skips validation and always runs the task.use_gitignore: If set totrue(at root or task level), Task will exclude files matched by.gitignorefromsourcesandgeneratesresolution.
version: '3' tasks: js: cmds: - esbuild --bundle --minify js/index.js > public/bundle.js sources: - src/js/**/*.js generates: - public/bundle.jsUnderstand the Taskfile structure
mainTaskfiles 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 totrue, 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: trueUse typed variables (booleans, integers, floats, and arrays)
mainStarting 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}}'Access experimental features via feature flags
mainTo 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.