Skip to main content

The active task

DataStar tracks a single active task: the work item the next release will be tied to. Once it is set, every place that needs a task ID (the Release Workflow wizard, MCP tools, the status bar) reads it from one place rather than asking you to enter the same value over and over.

The active task is scoped per workspace. On Git workspaces it is also scoped per branch, so switching branch switches the active task. On TFVC workspaces it is workspace-wide.

How DataStar finds it​

On every branch change (and when a workspace opens), DataStar resolves the active task in this order:

  1. Explicit assignment. If you have explicitly tied a task to this branch, that wins.
  2. Branch-name parse (Git only). If the branch name contains an ID matching the task tracker's pattern (e.g. feature/PROJ-123-add-index), DataStar uses it as an auto-detected task.
  3. None. If neither applies, there is no active task.

The pattern in step 2 comes from the connected task tracker. Without a task tracker connected, DataStar falls back to a generic ID pattern, so branch-name detection still works for the common PREFIX-NUMBER shape.

tip

On Git, branch-name detection means you usually do not need to assign anything yourself. Name your branches with the task ID and the active task tracks itself.

On TFVC​

The "task follows your branch" promise is a Git story. TFVC workspaces do not have branches in the same sense, so DataStar treats things differently:

  • No auto-detect. Step 2 above is skipped. There is no branch name to parse.
  • One default per workspace. The active task is whatever you last explicitly assigned. It survives across sessions until you re-assign or clear it.
  • No automatic cleanup. TFVC workspace mappings are not enumerable in the way Git branches are; the stale-assignment cleanup below does not apply.

The status-bar chip and every consumer (wizard, MCP) still work; they simply rely on you to set the value. Treat it as a session-survivable default rather than something that tracks itself.

The status bar chip​

A chip on the status bar shows the active task and is the primary place to manage it. The chip only appears when a task tracker is connected; otherwise it stays hidden.

It has three visual states:

StateWhat it shows
Set taskA "Set task" placeholder when nothing is resolved.
Auto-detected (Git only)The task ID, styled to signal it came from the branch name.
ExplicitThe task ID, styled to signal an explicit assignment.

Hovering the chip shows the task ID and (when known) the task title. On TFVC the chip only ever shows Set task or Explicit, since there is no branch name to auto-detect from.

Click the chip to open a flyout with:

  • An input to Assign a task ID. This becomes (or replaces) the explicit assignment for the current branch (or workspace, on TFVC).
  • Clear, which removes the explicit assignment. On Git the active task may immediately re-resolve via branch-name parse; on TFVC it goes to "Set task".
  • Open in browser, when the tracker provides a URL for the task.

Setting it explicitly​

You can make a task the active task in three ways:

  • From the status bar chip. Click the chip, click Assign…, pick or type an ID. Persisted immediately for the current branch (Git) or for the workspace (TFVC).
  • From the Release Workflow wizard. Step 1 has an Associate with branch checkbox (Git only). Tick it before advancing and the picked task is remembered as the active task.
  • Automatically, when you create a branch from a template (Git only). If your workspace has a branch-name template (e.g. feature/{taskid}-...) and you create a branch through DataStar with a task ID, the template both names the branch and sets it as the active task in one step.

The assignment is stored locally and is not pushed to your version-control remote or shared with teammates.

What reads from it​

Any place that needs a task ID and can sensibly default to the current one does so:

  • Release Workflow wizard. Step 1's ID field is pre-filled from the active task.
  • MCP tools. Four tools accept taskId as optional and fall back to the active task when it is omitted: import_basket_from_task, manage_deployment_file, get_deployment_file_storage_info, and generate_reversal_scripts. If there is no active task either, they fail with a message asking the agent to pass taskId explicitly or for the user to set one via the status bar.

Read more in the MCP Tool Catalog.

Branch lifecycle (Git)​

On Git workspaces, explicit assignments are cleaned up automatically:

  • Deleting a branch in DataStar removes the assignment for that branch immediately.
  • Deleting a branch externally (git branch -d, GitHub Desktop, web UI) is reconciled the next time the workspace opens. Stored assignments whose branches no longer exist are removed.

You will not accumulate stale entries over time, and a re-created branch with the same name will start clean (auto-detection will pick it up if the name still matches).

On TFVC there is no equivalent. The single per-workspace assignment persists until you change or clear it.

Limitations​

  • One task per scope. One task per branch on Git, one per workspace on TFVC. If you work two task IDs in the same scope, only one is the active task; switch by re-assigning from the chip.
  • No branch-rename detection (Git). Renaming a branch (e.g. git branch -m) orphans its assignment; the startup sweep eventually clears it. Re-assign on the new branch name when you need to.

See also​

Last updated on