Atlassian

Installs acli (the official Atlassian CLI) and configures shell aliases and per-shell account selection.

What it does

• Installs and updates acli from Atlassian's own package sources: their apt repository on Debian, their Homebrew tap on macOS
• Registers acli in ~/.versions.d/ so versions reports its version
• Bash tab completion for acli
• Keeps Atlassian account selection per-shell (ACLI_ACCOUNT) so terminals never collide, see Per-shell isolation
• Shell aliases and functions for Jira, Confluence, and account selection

acli covers more than its published command reference suggests. Version 1.3.29 carries jira, confluence, admin, guard and rovodev command groups, while the reference page still lists only Jira and admin. Check acli --help on the version you have rather than the docs.

Variables

The role installs from Atlassian's package sources, so acli tracks those and takes no version pin, the same as the ansible, docker and terraform roles. What you can override is the shell surface:

Variable	Default	Description
atlassian_aliases	atlassian, jira, confluence	Aliases written to ~/.profile.d/aliases/atlassian.sh
atlassian_functions	the four functions below	Shell functions the role generates
atlassian_completions	account completion	Completion bindings per function

Claim your own shorter aliases:

atlassian_aliases:
  atlassian: "acli-account"   # default: acli-account
  j: "acli jira"              # default alias is the full word `jira`
  c: "acli confluence"        # default alias is the full word `confluence`

Aliases

Alias	Command	Description
atlassian	acli-account	Show / switch the Atlassian account
jira	acli jira	Jira Cloud commands
confluence	acli confluence	Confluence Cloud commands

Functions

Function	Description
acli	Wraps the binary to scope its config to the selected account
acli-authenticate	Select an account and run the OAuth login in one step
acli-account	Show the current Atlassian account, or switch to a named one

Authentication

The role installs the CLI but leaves you signed out, so nothing writes credentials during an apply. Sign in once per account with acli-authenticate, which selects the account and then runs the interactive OAuth login. One login covers both Jira and Confluence:

acli-authenticate personal
acli-authenticate company

For a headless host, authenticate per product with a site, an email, and an API token from id.atlassian.com on standard input. Select the account first so the credential lands in its own home:

acli-account company
echo "$TOKEN" | acli jira auth login --site company.atlassian.net --email you@company.com --token
echo "$TOKEN" | acli confluence auth login --site company.atlassian.net --email you@company.com --token

Multiple accounts

acli does hold several accounts natively, through acli auth switch. What it cannot do is hold a different one per terminal: the switch rewrites the shared config under ~/.config/acli, so every open shell moves with it. That is the case per-shell selection exists to solve.

acli offers no lever to move that config. There is no config-directory flag, XDG_CONFIG_HOME is ignored, and the binary carries no ACLI_* environment variable. What does work is scoping HOME for the length of one call, so the acli function does exactly that:

HOME="$HOME/.config/acli-accounts/$ACLI_ACCOUNT" command acli "$@"

Each account then keeps a home of its own under ~/.config/acli-accounts/<name>, with acli's usual .config/acli inside it. acli-account <name> exports ACLI_ACCOUNT; run it with no argument to show the current account and list the ones you have:

acli-account company     # select the account for this shell
acli-account             # show the current one, and list the rest

With no account selected the wrapper stays out of the way and acli uses ~/.config/acli as it normally would, which makes an existing single-account setup the implicit default.

Per-shell isolation

Account selection lives in the ACLI_ACCOUNT environment variable scoped to the current shell, never in a shared current account key. acli-account exports it rather than running acli auth switch, so picking an account in one terminal cannot change which Atlassian site another terminal acts on.

Because selection is env-var driven, every terminal holds its own account, including a coding agent's. This is the per-shell context isolation concept applied to Atlassian.

Troubleshooting

unauthorized: use 'acli jira auth login' to authenticate The selected account has no credentials. Run acli-authenticate <name>, or check with acli-account that the shell is on the account you expect.

Commands work in one terminal and not another The two shells are on different accounts, which is the point of the isolation. acli-account with no argument reports which one each is using.

Confluence tools missing after signing in to Jira The per-product token logins are separate. The top-level acli auth login covers both; a acli jira auth login does not grant Confluence.