[Proposal] Inline platform/arch key for commands

[leaanthony]

Firstly, thanks for such an awesome project!

I've been trying to write a simple taskfile that does slightly different things depending on platform/arch. This has led me to try the 2 current methods for doing this:

• Go Template method
• Multiple Taskfiles

The first is hard to read and I had issues with it outside of simple echos (easy to make invalid YAML). For multiple platforms, this would get messier:

- echo '{{if eq OS "windows"}}windows-command{{else}}unix-command{{end}}'

The second option can lead to many Taskfiles on disk making it harder to manage.

As an example scenario, I want to run a go build on linux, darwin & windows but need to do slightly different things on each:

• On Windows, generate a .syso file
• Run go build
• On Darwin, create an app structure
• On Darwin, copy the app to the app structure
• On windows, copy the correct 3rd party dll for the architecture
• On linux, copy a .desktop file to the directory

For the templating option, Taskfile.yaml would be very messy and I'm not even sure it's achievable in any elegant way.
The multi-taskfile option would be better IMHO, but now there's potentially 4 task files and 1 main.go file which seems overkill, not to mention code duplication. I mean it's possible but....

When I break down the problem, I simply want to be able to run certain commands on certain platforms within a task. This led me to think about an alternative approach:

For a cmd, allow the following syntax: - [platform/arch:] command

Example:

version: '3'

tasks:
  build:
    cmds:
      - darwin: mkdir -p x/y/z
      - windows: winres -I app.manifest -o app.syso
      - go build
      - windows/386: copy ..\32bit\app.dll .
      - windows/amd64: copy ..\64bit\app.dll .
      - linux: cp ../app.desktop .

I've created a PoC and it's a reasonably simple change and works well. I'm not well-versed in Task and the nuances this may introduce so I thought I'd put it out there and see what people think. If there's agreement that it's a good addition, I'll create a PR so I can get feedback on the best way to implement it.

Cheers.

[andreynering]

Hi @leaanthony!

I agree that we can improve this use case. Needs a bit of discussion on how, though.

I'm curious to see your PoC work. If you could push it to a branch in your fork, or create a PR (whatever you prefer), so I can take a look, that would be helpful!

FYI, we have an open (and overdue) issue about having an if attribute able to control when a task/cmd will run: #608. That's a more generic solution, but would help in this use case.

That said, since checking for OS/Arch is a very common scenario, I think maybe a prop like on: [...] should be much cleaner:

on: [windows]
on: [amd64]
on: [linux, darwin]
on: [windows/amd64]

On a Taskfile:

version: '3'

tasks:
  build-windows:
    cmds:
      - go run windows.go
    on: [windows]

version: '3'

tasks:
  build-windows:
    cmds:
      - cmd: go run windows.go
        on: [windows]

No strong vs. your proposal to have as keys, but I think the implementation of on: would probably be easier and more generic, avoiding the need of declaring keys for each OS/Arch combination on the YAML definition.

[leaanthony]

Thanks @andreynering for your time in replying. I like your proposal to use the "on" keyword. I knocked up a quick PR to achieve this. I'm sure there's plenty wrong with it but it does work and makes quite a good starting point. Any feedback welcome!

One thought: the word "On" to me implies triggers/events, almost like a pre-requisite. Would the word "platforms" be better in this case?

[andreynering]

@leaanthony Yes, on was my initial thought, but I'm open to ideas. platforms seems much better, indeed.

[leaanthony]

Renamed On -> Platforms and updated PR. I wasn't sure how to test using the testdata Taskfile.yml I've added other than manually, without a bunch of "if I'm running on OS A then expect result B" type commands. Thoughts?

[ccxuy]

This is not enough, if or custom label is still needed.
There are many different platform or OS, or self-maintain server settings, the workflow need to deal with different situation.