Support unique identifiers in group outputs for GitLab CI job log section names

[outofrange]

Description

GitLab CI support job log sections using markers like:

• \e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME\r\e[0KTEXT_OF_SECTION_HEADER
• \e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K

The issue I'm facing is that I haven't found a suitable way for templating SECTION_NAME for the group start/end property:

• a slugged variant of {{.TASK}} or {{.ALIAS}} isn't unique for repeated executions of the same task, resulting in duplicate identifiers
• {{uuid}} would return different ids when evalauted for group start and end string

Maybe I overlooked an existing special var / function I can use for this?

A special variable like {{.TASK_EXEC_UUID}}, which would be unique for each individual execution of a task, should help for templating unique GitLab CI section names.

[vmaerten]

Hello !
We can use uuid templating function like :

# Advanced object format
output:
  group:
    begin: "::group::{{uuid}}"
    end: "::endgroup::"
    error_only: false

Reference : https://taskfile.dev/docs/reference/templating#utility-functions & https://taskfile.dev/docs/reference/schema#output

[outofrange]

But how would I reuse the same generated uuid in SECTION_NAME for the section_end part of \e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K?

[vmaerten]

Hey @outofrange, you're right sorry I've read too fast.

Your TASK_EXEC_UUID idea would definitely work. That said, I think we should aim for first-class support for CI systems out of the box.

Proposed approach

Introduce a dedicated output: gitlab mode (same level as group, prefixed, interleaved).

This mode would:

• Emit the correct GitLab section format
• Generate a unique section ID internally (so users don’t have to deal with matching constraints)
• Handle timestamps so GitLab can display section durations
• Support options like collapsed: true and error_only

---

Where should this be configured?

I explored three options:

1. output: gitlab in the committed Taskfile

Pros

• Simple to configure
• Works out of the box

Cons

• Penalizes local development: everyone gets GitLab-formatted output unless they override it
• Feels like the wrong layer: Taskfile is shared code, while output is environment-specific

---

2. --output gitlab in .gitlab-ci.yml

Pros

• Explicit and easy to understand
• Keeps concerns well separated

Cons

• Requires modifying every task invocation in CI configs
• Can become repetitive and harder to maintain

---

3. Auto-detection via GITLAB_CI=true

(Similar to #2568 with emitCIErrorAnnotation)

Pros

• Zero configuration for users
• Works automatically in CI

Cons

• Risky: unlike error annotations (which are additive), section markers wrap and transform the entire output
• Could break users who already define manual sections or parse logs downstream
• Larger blast radius due to implicit behavior

---

Proposed compromise

A hybrid approach: introduce a new output-ci-auto flag in .taskrc.yml.

Behavior

• Only activates when no explicit output is configured (via Taskfile or CLI)
• Automatically selects the appropriate CI output when running in CI

So:

• task locally : interleaved (default)
• task in GitLab CI + flag enabled : gitlab
• Explicit config (--output or output: in Taskfile) : always takes precedence

Why this works well

• Opt-in : no surprises for existing users
• Keeps Taskfile environment-agnostic
• No need to modify CI configs
• Centralized config via .taskrc.yml
• Naturally extensible to GitHub Actions, Azure, etc.

---

Would love feedback on the flag behavior before I move forward with implementation: @andreynering @pd93

[outofrange]

I quickly let an agent set up a fork with TASK_EXEC_UUID implemented, which works for unique section identifiers - but I discovered another issue: generating the timestamp with {{now | unixEpoch}} doesn't work, because group-begin and group-end are evaluated at the same time when task execution starts, rendering the exact same timestamp (causing GitLab to show a duration of 00:00 for each section).

So first class support would be even better!

output-ci-auto would totally work for me, as long as it can be set through CLI and/or env variables as well - I don't maintain .taskrc.yml files yet.
But I think that would be "automatically" the case?

[trulede]

@vmaerten this is for gitlab? In github you can detect CI with envar CI=true.

But, do I understand that the grouped output could work ... because that seems like more general solution. For instance a UUID function with a seed value (which could be the task hash value):

output:
  group:
    begin: "section_start::{{.TIMESTAMP}}:{{uuid5 .TASK_HASH}}"
    end: "section_end::{{.TIMESTAMP}}:{{uuid5 .TASK_HASH}}"
    error_only: false

Then it would be a case of finding a suitable UUID function. Or perhaps the existing task hash would actually be sufficient.

Changes are then limited to a new task envar (TASK_HASH, exposing the internal task hash value) and perhaps a new uuid function. And its possible to configure for any CI like system.

[outofrange]

CI=true is also available as predefined variable in GitLab!