A task runner / simpler Make alternative written in Go

Overview

Task

Task is a task runner / build tool that aims to be simpler and easier to use than, for example, GNU Make.

See taskfile.dev for the documentation.

Comments
  • Roadmap to v4

    Roadmap to v4

    Hi everybody,

    There were some discussions at #694 with regard to ideas of a possible future major release. GitHub discussions are not too good for these discussions so I decided to open this issue to be more centralized and visible (issues can be pinned).

    Also, that probably needs some direction and organization, as having more people involved means we now have different opinions we need to reconcile.

    @ghostsquad started working on some ideas on his fork, but I consider that to be a Proof of Concept ™️, and things will likely be different in its final version in the repository.

    This issue is a WIP and will be iterated as time passes.


    Principles

    • Minimal breaking changes
      • Most people should be able to change version: '3' to version: '4' and their Taskfile should keep working mostly the same, with minimal changes
      • This means no unnecessary changes to the schema, like renaming cmds to something else, for example. Most changes should be for new features
      • The same applies to avoiding changes to CLI flags
      • There may be exceptions, of course, but they needs a good justification. Variables will probably be the biggest one, as @ghostsquad has a proposal to make they lazy.
      • Also, for Taskfiles with version: '3' everything should keep working as before, with rare exceptions
      • I'm undecided about remove code related to keep version: '2' working
    • Development process
      • Pull requests should be atomic, one for each feature, so they can be reviewed in isolation and discussion can happen with more efficiency about each feature (with regard to UX and implementation)
      • Tests should be written covering the relevant code

    Steps

    Preparation

    • We should try to do this in the master branch IMO, to avoid future conflicts between master and v3
    • Code re-organization? We have some old directory structure and may want to improve that
    • Tests refactor? Would help as we will write new tests for v3 stuff.
      • Some ideas here: #699

    Implementation

    • At this point we may decide to have a v3 branch
    • Variables refactor
      • Probably the first step, as it's so core an will affects discussions about other changes
      • Make then lazily evaluated (@ghostsquad's proposal, #694)
      • Apply that to ENVs in the process? #693
      • Non-string variables? #140
    • Loop / files / matrix
      • Supports looping files? #82
      • Some kind of matrix like GitHub Actions? #675
      • We probably need a proposal to try to solve both use cases
      • #82 is very old but still valid. It's something Make can do that Task still can't
    • We need to figure it out if/how to proceed about setup: and hooks proposals: #204, #667, #668
    • ...

    This is a ongoing document and will be improved...

    meta 
    opened by andreynering 45
  • Add

    Add "imports" or "includes"

    Hi,

    Request

    Add the possibility to use import or includes to imports some others tasks. With the default strategy as namespace.

    Example

    File: docker/v1.0/Taskfile.yaml

    version: "2"
    
    task:
      build:
        cmds:
          - docker build...
    

    File: go/v1.0/Taskfile.yaml

    version: "2"
    
    task:
      build:
        cmds:
          - go build ...
    

    File (in my project): Taskfile.yaml

    imports:
      docker: https://.../docker/v1.0/Taskfile.yaml
      go: file://.../go/v1.0/Taskfile.yaml
    

    — or —

    includes:
      docker: https://.../docker/v1.0/Taskfile.yaml
      go: file://.../go/v1.0/Taskfile.yaml
    
    task:
      build:
        - task: "docker:build"
        - task: "go:build"
    

    How to use?

    task go:build go:docker
    

    — or —

    task build
    

    Finally

    What do you think?

    feature on hold 
    opened by JulienBreux 42
  • Multiple tasks with the same dependency should run dependency once!

    Multiple tasks with the same dependency should run dependency once!

    UPDATE: This is a general feature request to not run equal dependencies more than once. E.g. if task A and task B both depend on taskC, running both task A and task B in parallel (witin one instance of task), should be able to resolve the dependencies so that taskC is only run once, and this is the interesting port, if it's equal, which we will get to next.

    what makes a task equal?

    Since you can pass variables to tasks, it's not enough to just look at the name. The best option is probably to rely on a hash of the name + sorted and resolved input variables. A close second could be to rely on unresolved but still sorted input variables, which is not perfect, but could be an acceptable trade-off if it's somehow easier in code.


    Original description

    I have multiple tasks in my Taskfile that depend on a single task called go-dep that runs the command glide install. When I run task to build multiple targets, I would expect go-dep to be called at most 1 time (zero if it's found to be up-to-date). Instead, I see it's called once for each task that depend on it:

    $ task
    task: No argument given, trying default task
    glide install
    glide install
    glide install
    glide install
    

    PS! go-deps in this case is called with no vars, but the rule should really apply to run a dep at most 1 time when the vars are exactly the same.

    feature 
    opened by smyrman 25
  • dirname of current Taskfile

    dirname of current Taskfile

    I often want to use the directory of where the Taskfile is located as an input to other commands (not the current working directory), but it seems like sprig really locks down access to the filesystem.

    Is this possible to do with Task as a first-class idea?

    For example, something like:

    tasks:
      show-current-dir:
        desc: "show where Task is executing from"
        cmds:
          - echo {{ .TASKFILE_LOCATION }}
    

    Note that this isn't the same as just using $PWD or -d because the working directory might be different; Task should probably provide this as a first-class feature if it doesn't already.

    feature 
    opened by fj 22
  • Roadmap to version 3

    Roadmap to version 3

    This is a general issue to track proposals with small or big breaking changes, that could be released in the next major version.

    This list is a work in progress and can change at any time.

    Development is happening on the v3 branch.

    Cleanup

    • [x] Change module name from github.com/go-task/task/v2 to v3
    • [x] Remove all code related support of version 1 (#237)
    • [x] Remove automatic inclusion of Taskvars.yml and Taskfile_{{OS}}.yml. This was done before we had a generic inclusion of Taskfiles implemented. We should add options to
      • [ ] Don't include the file if it doesn't exist
      • [x] Allow interpolation on the file name to make it possible to include a OS specific file
    • [x] Finally delete the vendor directory? (#214)

    Breaking changes

    • [x] Added global method: option. Default changed from timestamp to checksum (#246)
    • [x] Refactor vars and templates to reduce the number of bugs and undesired behavior (#218)
    • [ ] Make CLI arguments override everything (#181) (EDIT: What about #336?)
    • [ ] Make up-to-date resolution work when only "generates" is given (#187)
    • [ ] Don't run the same dependency (with the same args) more than once by default (#53, #193)
    • [ ] Allow forcing specific tasks (#189)

    New stuff

    • [x] Colored output messages (#207)
    • [x] Expose .TIMESTAMP and .CHECKSUM to status: (#216)
    • [x] Allow shorter syntax for tasks with default configuration (#194)
    • [ ] Allow use as a library (#121)

    Documentation

    • [x] Mention changes related to method: (shouldn't also check the main guide)
    • [x] Update "Taskfile versions" article

    There are more issues and feature request that could be added to this release.

    proposal v3 meta 
    opened by andreynering 22
  • Allow commands run in parallel

    Allow commands run in parallel

    For some startup tasks or cleanup paths commands could run in parallel while others should be run in order. Add a Parallel property to task to allow switching between modes

    enhancement 
    opened by sascha-andres 22
  • Message to the community

    Message to the community

    Hi everybody 👋

    Once in a while, people ask me why the development is slow, questions got unanswered, bug reports are not responded, features not added, PRs not reviewed, etc.

    The answer is simple: the project has grown to become bigger than I ever expected. With a full time job and a life outside work, I have limited time to dedicate to this project. More demand is generated from users than I could keep up even if I doubled the time I dedicate to this project.

    So first of all I'd like to ask for your patience and understanding.

    Secondly, I'd like to hear opinions and ideas on how to keep the project moving.

    And lastly, I'ld like to ask for some help. I had two other people with write access to the repo in the past, but they quickly lost interest in the project. Other than that short period, I've being alone. You could help:

    1. Answering questions, validating bug reports, giving opinions on feature requests, closing issues/PRs when they do not make sense, etc.
    2. Writing code and reviewing pull requests, specially bug fixes and small features. (I'd still like to have the final word on bigger features as sometimes people suggest changes that breaks backward compatibility or add more complexity than desired)
    3. Some people have helped the project by contributing to mvdan/sh as well, and I'm thankful for that. Help on mvdan/sh#93 in particular would hugely benefit Windows users if you're interested to help.
    meta 
    opened by andreynering 19
  • Display task summary

    Display task summary

    Adding a --summary flag for task to get more a summary of the task

    See #107

    New field in task called summary

    version: '2'
    tasks:
      release:
        deps: [build]
        summary: |
          Release your project to github
    
          It will build your project before starting the release it.
          Please make sure that you have set GITHUB_TOKEN before starting.
        cmds:
          - your-release-tool
      build:
        cmds:
          - your-build-tool
    

    Output for task --summary release:

    task: release
    
    Release your project to github
    
    It will build your project before starting the release it.
    Please make sure that you have set GITHUB_TOKEN before starting.
    
    dependencies:
     - build
    
    commands:
     - your-release-tool
    

    Behaviour:

    • --summary will not execute the task
    • --summary will display the summary of a task (see above)
    • --summary will use description as fallback, if summary does not exist
    • --summary will output a warning (or information), if no description/summary is present
    • --summary will output the dependencies if there are any
    • --summary will output the commands if there are any

    Tests:

    • Because there are a lot of edge-cases I decided to extract out a package (summary), which is completly unit tested with above named edge cases.
    • There is an integration like test in task_test.go

    Documentation is present for that feature

    opened by jaedle 19
  • Add support for delegating CLI arguments with

    Add support for delegating CLI arguments with "--" and a special CLI_ARGS variable

    Does go-task currently offer the option of "passthrough" arguments? For example, if I have currently have a task to run the AWS CLI out of a Docker container:

    tasks:
      aws:
        cmds:
          - docker-compose run --rm aws		
    

    Is it possible to have the ability for a command like task aws -- ls s3://my-bucket to be translated to docker-compose run --rm aws ls s3://my-bucket, meaning task will pass through anything after -- to the underlying shell command?

    This is a more convenient way to pass extra variables compared to the current approach: task write-file FILE=file.txt "CONTENT=Hello, World!". Currently, using this approach allows me to write task aws CMD="ls s3://my-bucket" but the extra variable definition and quotes creates a lot of friction that I think can be alleviated with my proposal.

    If this is not possible, it would be a really nice capability to have in the future.

    feature proposal variables 
    opened by huy-nguyen 17
  • Allow using URLs within includes

    Allow using URLs within includes

    This is my first proposal to add includeable Taskfiles over http.

    The config looks like the following:

    includes: 
      moo: 
        path: https://raw.githubusercontent.com/go-task/task/master/Taskfile.yml
        cache: 30s
      foo: https://raw.githubusercontent.com/tonobo/task/master/Taskfile.yml
      hui: 
        path: ./
        flush_includes: yes
    

    References: #98

    feature on hold 
    opened by tonobo 17
  • Cannot correctly modify environment variable PATH for use in task commands

    Cannot correctly modify environment variable PATH for use in task commands

    • Task version: 2.5.1
    • OS: Windows 10 Professional (64-bit)
    • Example Taskfile showing the issue:
    # https://taskfile.dev
    
    version: '2'
    
    tasks:
    
      a:
        cmds:
          - echo "Task a"
          - echo $PATH
    
      b:
        cmds:
          - echo "Task b"
          - echo "{{.PATH}}"
    
      c:
        env:
          PATH: tools
        cmds:
          - echo "Task c"
          - echo $PATH
    
      d:
        env:
          PATH: tools
        cmds:
          - echo "Task d"
          - echo "{{.PATH}}"
    
      e:
        env:
          PATH:
            sh: echo "tools;$PATH"
        cmds:
          - echo "Task e"
          - echo $PATH
    
      f:
        env:
          PATH:
            sh: echo "./tools;$PATH"
        cmds:
          - echo "Task f"
          - echo $PATH
    
      g:
        env:
          PATH:
            sh: echo "$(realpath ./tools);$PATH"
        cmds:
          - echo "Task g"
          - echo $PATH
    

    Hello. Firstly, thank-you for Task. It has, overall, made my development life easier and more pleasant.

    I don't know if the problem I have is a bug or if I simply don't understand the correct way to achieve my goal. I'd like to be able to modify the environment variable PATH (either prepending or appending a project-specific directory to the existing value), but I can't figure out how to do this using the set of commands available within Taskfiles.

    To provide context, my Taskfile is for use in building go applications. Some applications (projects) require project-specific build tools/helpers that I place in a top-level tools subdirectory (i.e., <project name>/tools). Note that my Taskfile resides at <project name>/Taskfile.yml. I wish to use the go generate command, which effectively requires that external generation tools be accessible via PATH, so I must add <project name>/tools to PATH before running go generate in the task.

    While I'm working in Windows, I'm making effective use of busybox-w32 to provide a fairly comprehensive set of what are otherwise Linux tools, so things like cp, echo and realpath are available. I've also tried this via WSL such that things are more like a real Linux environment, with the same results.

    The output I get from the above Taskfile (when run under sh or bash via WSL) is as follows (results in native Windows are the same):

    $ task a; task b; task c; task d; task e; task f; task g                                             
    echo "Task a"                                                                                        
    Task a                                                                                               
    echo $PATH                                                                                           
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
    echo "Task b"                                                                                        
    Task b                                                                                               
    echo "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"      
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
    echo "Task c"                                                                                        
    Task c                                                                                               
    echo $PATH                                                                                           
    tools                                                                                                
    echo "Task d"                                                                                        
    Task d                                                                                               
    echo "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"      
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
    echo "Task e"                                                                                        
    Task e                                                                                               
    echo $PATH                                                                                           
    tools;/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games       
    echo "Task f"                                                                                        
    Task f                                                                                               
    echo $PATH                                                                                           
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games             
    echo "Task g"                                                                                        
    Task g                                                                                               
    echo $PATH                                                                                           
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
    

    Tasks a, b, c and d are just simple tests; it's tasks e, f and g that illustrate the real issue. Task e works correctly, prepending tools to the current PATH, but neither f nor g have any effect. Task g is the closest to what I need in terms of operations (i.e., adding the absolute path of a project-specific directory).

    I'd greatly appreciate any input you could provide on this issue. Thanks in advance.

    bug 
    opened by i-am-david-fernandez 16
  • Command-level dir (cd)

    Command-level dir (cd)

    Problem

    Very often, when we use Taskfile, we want to call commands from some directive, required for this commands.

    Current Solution

    Currently, we can do this this way:

    tasks:
      create:
        cmds:
          - |
            cd "dir1/dir2/dir2
            pwd
            echo "Hello"
            cd ..
            echo "Hello"
            pwd
    

    The problem with this solution, is that we can't use cmd properties (like ignore_errors or vars) for each command separately. We run whole job as one command, so we can't use other feature for taskfile.

    The second way we can do this, is by making multiple task commands:

    tasks:
      create:
        cmds:
          - task: hello1
          - task: hello2
       
      hello1:
        dir: 'dir1/dir2/dir2'
        cmds:
          - echo "Hello" && pwd
      
      hello2:
        dir: 'dir1/dir2'
        cmds:
          - echo "Hello" && pwd
    

    But this is not ideal way either, because we create new sub-commands only to call them from one another "parent" command, so we making redurant task commands we can avoid creating.

    Proposal

    We can implement command-level dir definition, like ignore_errors for command:

    tasks:
      foo:
        cmds:
          - cmd: echo "Hello from" && pwd
            dir: "directory"
    

    There is a different ways to do it thought. We can save current dir if we assume command are sequential, as we do cd. There is some questions about the api. First of all, its about dir relativeness. We can make:

    • dir always relative to the parent (task dir) (1)
    • dir relative to last command dir (2)

    (1) Example:

    # dir: src
    tasks:
      foo:
        cmds:
          - cmd: echo "Hello from" && pwd # Hello from src/directory
            dir: "directory"
          - cmd: echo "Hello from" && pwd # Hello from src/directory2
            dir: "directory2" 
    

    (2) Example:

    # dir: src
    tasks:
      foo:
        cmds:
          - cmd: echo "Hello from" && pwd # Hello from src/directory
            dir: "directory"
          - cmd: echo "Hello from" && pwd # Hello from src/directory/directory2
            dir: "directory2" 
    

    And then:

    • dir as cmd child (3)
    • dir as cmds child (4)

    (3) Example:

    # dir: src
    tasks:
      foo:
        cmds:
          - cmd: echo "Hello from" && pwd # Hello from src/directory
            dir: "directory"
          - cmd: echo "Hello from" && pwd # Hello from src/directory/directory2
            dir: "directory2" 
    

    (4) Example:

    # dir: src
    tasks:
      foo:
        cmds:
          - dir: "directory"
          - echo "Hello from" && pwd # Hello from src/directory
          - dir: "directory2" 
          - echo "Hello from" && pwd # Hello from src/directory/directory2
    

    So as you can see, there is 4 variations: we need to chose (1) or (2), with (3) or (4).

    I think best combination down there is "(2) + (4), because it seems to me, that in many use cases you want to run multiple commands in one dir change. Also, in this variation, dir would be semantically familiar to console cd command:

    # dir: src
    tasks:
      foo:
        cmds:
          - dir: "directory"
          - echo "Hello 1" 
          - echo "Hello 2" 
          - echo "Hello 3" 
          - dir: ".."
          - echo "Hello 4" 
          - echo "Hello 5" 
    

    We can name this "cd" as command, to make this more semantically correct:

    # dir: src
    tasks:
      foo:
        cmds:
          - cd: "directory"
          - echo "Hello 1" 
          - echo "Hello 2" 
          - echo "Hello 3" 
          - cd: ".."
          - echo "Hello 4" 
          - echo "Hello 5" 
    

    In case of having task-level dir, with cd we will start moving relative to task-level dir:

    # dir: src
    tasks:
      foo:
        dir: "directory1"
        cmds:
          - cd: "someDir2" # directory1/someDir2 
          - echo "Hello 1"
          - echo "Hello 2" 
          - echo "Hello 3" 
          - cd: "someDir3" # directory1/someDir2/someDir3
          - echo "Hello 4"
          - echo "Hello 5" 
    
    feature 
    opened by MadL1me 3
  • Included taskfiles inherit parent taskfile directory instead of root taskfile directory

    Included taskfiles inherit parent taskfile directory instead of root taskfile directory

    Not sure if this is intended behaviour when double nesting included taskfiles or not. Example below:

    Base Taskfile includes another Taskfile in the tasks subdirectory.

    # Taskfile.yml
    version: '3'
    
    includes:
      included: ./tasks/included.yml
    

    Included Taskfile includes a utility Taskfile using the new internal keyword. It then defines 2 tasks. One to print the current directory and one to call a task in the util Taskfile that also prints its current directory.

    # tasks/included.yml
    version: '3'
    
    includes:
      util:
        taskfile: ./util.yml
        internal: true
    
    tasks:
      pwd:
        cmds:
          - pwd
    
      util-pwd:
        cmds:
          - task: util:pwd
    
    # util.yml
    version: '3'
    
    tasks:
      pwd:
        cmds:
          - pwd
    

    Output:

    ❯ task included:pwd
    task: [included:pwd] pwd
    /abs/path/to/project
    
    ❯ task included:util-pwd
    task: [included:util:pwd] pwd
    /abs/path/to/project/tasks
    

    The utility Taskfile is getting the working directory of the included Taskfile not the root Taskfile. I can work around this by doing something like this in the included Taskfile:

    includes:
      util:
        taskfile: ./util.yml
        internal: true
        dir: ../            # <-- fixes problem
    

    This isn't really a problem per se, but it wasn't what I was initially expecting and was wondering if this is the intended behaviour or not. Obviously, any change here would be a breaking one.

    • Task version: 3.18
    • Operating System: Linux
    needs triage 
    opened by pd93 0
  • Enable GHA output grouping prevents real-time streaming of stdout/stderr

    Enable GHA output grouping prevents real-time streaming of stdout/stderr

    Based on https://discord.com/channels/974121106208354339/1042886315856892015 we had the following observations:

    • Enabling GHA grouping via output: group does disable progressive stdout streaming. This can be problematic if user has a long-running single script, as he would get zero output on the web console
    • GHA allows streaming when grouping is used
    • By adding interactive: true to a specific command, we can avoid unexpected combination from parallel task executions
    • interactive: true cannot be defined at top level and adding it to each individual command from each individual task adds too much noise to config
    • A considerable number of users may not need parallel task runs
    • Maybe we can we enable GHA output grouping without having to customise Taskfiles? (detect GH specific env vars)

    Feedback welcome to this ticket, especially as we do not know exactly what would the optimal behavior.

    enhancement 
    opened by ssbarnea 1
  • feat: add --json flag to be used by editor extensions

    feat: add --json flag to be used by editor extensions

    a new --json flag works only with the --list and --list-all flags to format those task lists as JSON output.

    • can't use --json by itself:
    go run ./cmd/task --taskfile ./testdata/output_group/Taskfile.yml hello --json | jq .
    task: --json only applies to --list or --list-all
    exit status 1
    
    • --json --list ignores tasks that are missing descriptions:
    go run ./cmd/task --taskfile ./testdata/output_group/Taskfile.yml hello --json --list | jq .
    {
      "tasks": []
    }
    
    • --json --list-all includes all tasks
    go run ./cmd/task --taskfile ./testdata/output_group/Taskfile.yml hello --json --list-all | jq .
    {
      "tasks": [
        {
          "name": "bye",
          "desc": "",
          "summary": "",
          "up_to_date": false
        },
        {
          "name": "hello",
          "desc": "",
          "summary": "",
          "up_to_date": false
        }
      ]
    }
    

    this PR includes a temporary WIP (work in progress) commit with additional detail printed to the console around the three failing tests; this commit is intended to help illustrate what is happening when these tests expect that we print nothing to the console so that we can review and confirm that we want to fix the code to maintain that expectation or perhaps update the expectation to provide more detailed output to clients and users.

    may resolve #764

    opened by davidalpert 0
  • Publish `task` as a Python package

    Publish `task` as a Python package

    I'd love to use task as the task runner in a Python project without requiring developers to install task manually. In my opinion, it is much better to use task over the plethora of language-specific task runners because it tends to be more feature-rich than many alternatives (as far as I can tell) and can be used for projects independent of their programming languages across all major operating systems without requiring a runtime (like the Python interpreter) thanks to the compiled Go binaries. I'd hope that task would gain further adoption with additional language-native packages and development efforts would focus on this project rather than being scattered across the language-specific alternatives.

    I believe a Python package could be created quite easily with some inspiration from the following projects:

    • https://github.com/shellcheck-py/shellcheck-py
    • https://github.com/editorconfig-checker/editorconfig-checker.python

    Would you be open to accepting a contribution that adds support for publishing a Python package?

    Related to #870.

    releasing 
    opened by sisp 1
  • Issue, `label` Directive - fails to work when directive  `output: prefixed` in Taskfile

    Issue, `label` Directive - fails to work when directive `output: prefixed` in Taskfile

    Problem:

    The directive label's function is to allow a task to output a text string, other than the task name when the task is executed.

    In the official documentation states that label:

    'Overrides the name of the task in the output when a task is run. Supports variables.'

    If the label directive is set for a task, say to Hello with label: 'Hello' and the directive output: prefixed is also included in the Taskfile, the output is not as expected.

    Further, the outcome is the same if the label text is set dynamically using a Task variable.

    See the section 'Analysis' below.

    Test Taskfile.yml

    The Taskfile below contains two tasks one where label is a static string and one task where the label is from a dynamically loaded task variable.

    	version: '3'
    	
    	output: prefixed
    	
    	vars:
    	  VERSION: '0.2'
    	  BACKUP_TIME:
    	    sh: date +"%Y-%m-%d_%H:%M:%S"
    	  SYSTEM_ID:
    	     sh: |
    	         hostname
    	  BACKUP_ID: '{{.SYSTEM_ID}}_{{.BACKUP_TIME}}'
    	
    	tasks:
    	  default:
    	    # Predefined string for label
    	    label:   'Hello'
    	    desc: Display Task variables
    	    cmds:
    	      - |
    	        echo "HostName:"{{.SYSTEM_ID}}
    	        echo "Backup_Time:"{{.BACKUP_TIME}}
    	        echo "Backup ID:" {{.SYSTEM_ID }}{{.BACKUP_TIME}}
    	        echo "Version:" {{.VERSION}}
    	
    	  dynamic:
    	    # Dynamic string for label
    	    label: '{{.BACKUP_ID}}'
    	    desc: Display Task variables with label set dynamically
    	    cmds:
    	      - |
    	        echo "HostName:"{{.SYSTEM_ID}}
    	        echo "Backup_Time:"{{.BACKUP_TIME}}
    	        echo "Backup ID:" {{.SYSTEM_ID }}{{.BACKUP_TIME}}
    	        echo "Backup ID 2:" {{.VERSION}}
    

    Output Generated and expected

    Output generated from the task default:

    	task: [Hello] echo "HostName:"MBP.local
    	echo "Backup_Time:"2022-11-14_13:41:47
    	echo "Backup ID:" MBP.local2022-11-14_13:41:47
    	echo "Version:" 0.2
    	
    	[default] HostName:MBP.local
    	[default] Backup_Time:2022-11-14_13:41:47
    	[default] Backup ID: MBP.local2022-11-14_13:41:47
    	[default] Version: 0.2
    

    Output expected from the task default:

    	task: [Hello] echo "HostName:"MBP.local
    	echo "Backup_Time:"2022-11-14_13:41:47
    	echo "Backup ID:" MBP.local2022-11-14_13:41:47
    	echo "Version:" 0.2
    	
    	[Hello] HostName:MBP.local
    	[Hello] Backup_Time:2022-11-14_13:41:47
    	[Hello] Backup ID: MBP.local2022-11-14_13:41:47
    	[Hello] Version: 0.2
    

    Output generated from the task dynamic:

    	task: [MBP.local_2022-11-14_13:42:39] echo "HostName:"MBP.local
    	echo "Backup_Time:"2022-11-14_13:42:39
    	echo "Backup ID:" MBP.local2022-11-14_13:42:39
    	echo "Backup ID 2:" 0.2
    	
    	[dynamic] HostName:MBP.local
    	[dynamic] Backup_Time:2022-11-14_13:42:39
    	[dynamic] Backup ID: MBP.local2022-11-14_13:42:39
    	[dynamic] Backup ID 2: 0.2
    

    Output expected from the task dynamic:

    	task: [MBP.local_2022-11-14_13:42:39] echo "HostName:"MBP.local
    	echo "Backup_Time:"2022-11-14_13:42:39
    	echo "Backup ID:" MBP.local2022-11-14_13:42:39
    	echo "Backup ID 2:" 0.2
    	
    	[MBP.local_2022-11-14_13:42:39] HostName:MBP.local
    	[MBP.local_2022-11-14_13:42:39] Backup_Time:2022-11-14_13:42:39
    	[MBP.local_2022-11-14_13:42:39] Backup ID: MBP.local2022-11-14_13:42:39
    	[MBP.local_2022-11-14_13:42:39] Backup ID 2: 0.2
    

    Analysis

    The label directive works for both static and dynamic values and does label the first instance of the task name as seen in line 1 of both sets of output.

    The label directive does not output the substitute name in the output strings from the echo commands, as requested by output prefixed directive. The output reverts to the task name.

    • Task Version 3.17
    • Operating System: OS X Version Monterey 12.6
    needs triage 
    opened by dsbitor 0
Releases(v3.18.0)
azqlite is a lightweight wrapper around Azure's SDK to interact with the Azure Storage Queue service in a simpler and more idiomatic way.

azqlite azqlite is a lightweight wrapper around github.com/Azure/azure-storage-queue-go to interact with the Azure Storage Queue service in a simpler

Jose Garcia 1 Mar 12, 2022
Docker-based remote code runner / 基于 Docker 的远程代码运行器

Docker-based remote code runner / 基于 Docker 的远程代码运行器

E99p1ant 35 Nov 9, 2022
A reverse engineered github actions compatible self-hosted runner using nektos/act to execute your workflow steps

github-act-runner A reverse engineered github actions compatible self-hosted runner using nektos/act to execute your workflow steps. Unlike the offici

null 101 Nov 26, 2022
dashd-go is an alternative full node dash implementation written in Go (golang)

dashd-go is an alternative full node dash implementation written in Go (golang)

Alex 0 Jan 26, 2022
LinkPage is a FOSS self-hosted alternative to link listing websites such as LinkTree and Campsite.bio

LinkPage LinkPage is a FOSS self-hosted alternative to link listing websites such as LinkTree and Campsite.bio Features Self hostable and open source

Rohan Verma 50 Sep 20, 2022
The open source public cloud platform. An AWS alternative for the next generation of developers.

M3O M3O is an open source public cloud platform. We are building an AWS alternative for the next generation of developers. Overview AWS was a first ge

Micro Services 2.2k Nov 22, 2022
An open source alternative to terraform enterprise.

oTF An open source alternative to terraform enterprise. Functionality is currently limited: Remote execution mode (plans and applies run remotely) Sta

Louis Garman 99 Nov 20, 2022
Samantha 0 Feb 12, 2022
Provide task runtime implementation with pidfd and eBPF sched_process_exit tracepoint to manage deamonless container with low overhead.

embedshim The embedshim is the kind of task runtime implementation, which can be used as plugin in containerd. With current shim design, it is used to

Fu Wei 91 Nov 22, 2022
SLOs, Error windows and alerts are complicated. Here an attempt to make it easy

slo-computer SLOs, Error windows and alerts are complicated. Here's an attempt to make it easy SLO, burn_rate, error_rate, budget_spend are convoluted

last9 61 Nov 15, 2022
library to make building things with bitclout easy

cloutcli library to make building things with bitclout easy quick start demo cmd $ ./clout demo clout demo visualizegraph # make clout.gv graph fi

Andrew Arrow 18 Jul 27, 2022
go-awssh is a developer tool to make your SSH to AWS EC2 instances easy.

Describing Instances/VPCs data, select one or multiple instances, and make connection(s) to selected instances. Caching the response of API calls for 1day using Tmpfs.

kenju 5 Oct 11, 2021
Make any web accessible from your own host / domain

Web Mirror Based on reverseproxy Solution for: Website that only set 'X-Frame-Options' to 'sameorigin'. Hide website real url Content interception & m

Rubi 3 May 31, 2022
Stuff to make standing up sigstore (esp. for testing) easier for e2e/integration testing.

sigstore-scaffolding This repository contains scaffolding to make standing up a full sigstore stack easier and automatable. Our focus is on running on

Ville Aikas 37 Nov 2, 2022
Utility to make kubeseal --raw a bit easier.

ks Utility to make kubeseal --raw a bit easier. Building GOOS=windows GOARCH=amd64 go build -o ks-windows-amd64.exe ks.go GOOS=windows GOARCH=386 go b

null 1 Aug 19, 2022
Assignment - make a billing machine for the XYZ Cafe

Assignment In this assignment, you have to make a billing machine for the XYZ Cafe. The machine consist of a group of buttons each representing a uniq

null 0 Feb 9, 2022
Fast cross-platform HTTP benchmarking tool written in Go

bombardier bombardier is a HTTP(S) benchmarking tool. It is written in Go programming language and uses excellent fasthttp instead of Go's default htt

Максим Федосеев 3.9k Nov 22, 2022
:rocket: Modern cross-platform HTTP load-testing tool written in Go

English | 中文 Cassowary is a modern HTTP/S, intuitive & cross-platform load testing tool built in Go for developers, testers and sysadmins. Cassowary d

Roger Welin 634 Nov 19, 2022
Highly configurable prompt builder for Bash, ZSH and PowerShell written in Go.

Go Bullet Train (GBT) Highly configurable prompt builder for Bash, ZSH and PowerShell written in Go. It's inspired by the Oh My ZSH Bullet Train theme

Jiri Tyr 518 Nov 2, 2022