feat: colorize tasks in prefixed output

[AlexanderArvidsson]

Introduces a new option to the prefixed outputter to colorize the task names according to a sequence of colors. Helps distinguish what logging message comes from which task. As requested, this is now default behavior.

The color is deterministic in the sense that it indexes the tasks with a color according to the order they appear in logs. Once the color is determined, it sticks with that color for the rest of the task. If more tasks run than there are colors, the colors will loop.

This method was chosen over a seeded random, due to the risk that a seeded randomizer often results in duplicate colors, even with only a small number of tasks running. Instead, this ensures that no duplicate colors are chosen given the number of tasks does not exceed the number of colors. For example, using the prefix as the seed (through MD5 to get uint representation for rand.NewSource) gives the tasks "watch-templ" and "watch-tailwind" the same color. This is not preferable.

The sequence of colors was created to put semantic colors closer to the end of the sequence (red & green are success & failure colors), and the sequence consists of 2 parts, the non-bolded versions and the bolded versions. Non-bolded colors are chosen first, and bolded colors later, to provide more possible distinguishable colors with a large number of tasks. The test checks for proper looping of the color sequence by logging 16 tasks, whereas the sequence has 12 colors.

Screenshot

Checklist

• Backwards compatible
• Tests written & passing
• CLI flags updated (--output-prefix-color)
• Schema updated
• Docs usage & API reference updated

Future improvements

• Ability to configure exact color per task definition
• Configure the sequence of colors
• Determine the colors on setup according to the task list, instead of lazily as the logs come in. This ensures for a given set of tasks, the colors will always be the same.

[pd93]

I like this functionality. Just some initial, very high-level thoughts from a first skim through the changes. Open to some discussion around these comments before you make any further changes.

[pd93]

Is there a need to copy this file from github.com/go-chi/chi? We are already using github.com/fatih/color for handling colours in Task. Also, we have some code that allows users to specify custom colours using TASK_COLOR_X environment variables. It would be nice if this feature reused that code so that it works with prefixes too.

Additionally, reusing our logger means that the coloured output will be disabled with the --color flag and NO_COLOR environment variable.

I actually don't personally have an issue with this feature being the default behaviour (enabled by default), so long as it respects the flag/variable mentioned above. These colour settings already respect TTYs and since anyone using Task in a script should have colour disabled already, this change shouldn't break anything.

These changes would remove the need for the schema change and --output-prefix-color flags.

[AlexanderArvidsson]

I did come across github.com/fatih/color when I googled for common color packages, but I liked the simplicity from chi. However, I didn't realize task was already using fatih/color, and my main concern was bringing in a whole package just for colors. If it's already using it, I can migrate over to fatih/color instead!

Good point with the TASK_COLOR_X, I'll check it out!

I haven't checked into this right now, but I see a problem using the logger because it would introduce cyclic dependency; the outputter is independent of how it logs. The outputters create lines which are later spewed into the logger, so if the outputter depended on the logger and the logger requires lines created from the outputter, how would that work?
I'll dig into it a bit more to see if I can perhaps pass the logger instance into the outputter, so the outputters can utilize the logger's functionality with FOutf.
See my new reply :)

The logger doesn't seem to support bolded colors though, so we would be reducing the number of distinguishable colors by 2, so only 6 tasks guarantee unique colors before it starts looping.

I'd be glad to make it default behavior if you can clarify how I'd use the logger in the outputter, since with how it's structured that doesn't seem possible at the moment.

[AlexanderArvidsson]

I've now migrated to using the logger by passing the logger to the outputter (I hope that makes sense to do), and removed the file I copied from chi. Haven't pushed it yet though.
Much simpler than I thought, I should've checked that earlier (how did I not think about colors when the task cli itself outputs colors?), thanks!

Now the other part, should we skip bolded colors or should we add bolded colors support to the logger?
It would bring the number of (distinguishable) colors from 6 to 12, which I believe is worth it. They're only used if you have enough tasks anyway, but I guess it's fine without it.

[pd93]

should we skip bolded colors or should we add bolded colors support to the logger

No strong opinions on this. Some people might argue that (depending on your terminal), some of the "bold" ANSI colours are not very distinguishable from the regular ones, but I have no issue with them being added. They would need new environment variables with good names. I think the ANSI spec actually refers to them as "bright" colours, so maybe TASK_COLOR_BRIGHT_X is a good starting point.

This would actually allow those using fancier terminals with 8-bit colour to add different colours too if they wanted to (no love for orange in the ANSI spec 😆).

[pd93]

This is not necessarily relevant for this PR, but I had another idea for the future maybe...

It might be nice to support something similar to the functionality described in this popular issue for docker-compose. For example:

version: '3'

output: prefixed

tasks:
  default:
    cmds:
      - echo "foo"
      - ...
    prefix:
      text: 'print-{{.TEXT}}'
      color: red

This would allow people to set specific colours to any task. Obviously, if prefix is a string instead of an object, the color would be set to a default value of random.

Please don't feel like you need to do this now though. It can always be added later!

[pd93]

@AlexanderArvidsson Let me know if you need any help getting this over the line 👍

[AlexanderArvidsson]

@pd93 Sorry, had a lot of work last couple of weeks. I've already started and should get it ready soon :)
Thanks for offering to help, really appreciated!

[AlexanderArvidsson]

@pd93 Pushed changes to revert options and made color default, check it out if anything looks off!

[pd93]

@AlexanderArvidsson This just needs a quick rebase and then I think it's ready to go

[AlexanderArvidsson]

@pd93 Done and dusted! 🎉