docs(remote): document remote.auth under next instead of latest

The rebase landed these additions in the frozen copy served for the
released version, because the commits predated the split into next and
latest.
This commit is contained in:
Valentin Maerten
2026-08-23 12:22:38 +02:00
parent 1b7e67d1f9
commit d10460ab61
4 changed files with 61 additions and 61 deletions

View File

@@ -300,58 +300,6 @@ task --trusted-hosts github.com,gitlab.com -t https://github.com/user/repo.git//
task --trusted-hosts example.com:8080 -t https://example.com:8080/Taskfile.yml
```
#### `remote.auth`
- **Type**: `array of objects`
- **Default**: `[]` (empty list)
- **Description**: HTTP headers to send when downloading a remote Taskfile from
a given host
```yaml
remote:
auth:
- host: gitlab.com
headers:
PRIVATE-TOKEN: ${GITLAB_TOKEN}
- host: artifacts.example.com:8443
headers:
Authorization: Bearer ${ARTIFACTS_TOKEN}
```
This is the recommended way to authenticate a remote Taskfile. Unlike a
credential placed in the URL, the header never appears in your Taskfile, in the
confirmation prompt or in an error message, so the include URL stays safe to
commit.
Each entry applies to a single host, matched exactly and including the port if
the URL has one — the same rule as
[`remote.trusted-hosts`](#remote-trusted-hosts). Header values may reference
environment variables with `${VAR}` or `$VAR`, read when Task contacts the host.
An undefined variable expands to nothing, so the header is sent empty and the
server rejects it — prefer an environment variable over a literal value, which
cannot contain a `$` followed by a name.
The header your server expects depends on the service:
| Service | Header |
| ----------- | -------------------------------------- |
| GitLab API | `PRIVATE-TOKEN` (or `JOB-TOKEN` in CI) |
| GitHub API | `Authorization: Bearer <token>` |
| Artifactory | `X-JFrog-Art-Api` |
There is no CLI flag or environment variable for this option: a token given on
the command line would be visible to any process listing it.
::: warning
Headers are only sent to the host they are configured for. If that host answers
with a redirect to another one, the request follows the redirect **without**
them, and will likely fail — point the URL at the final host instead. Headers
are also HTTP-only: a Taskfile fetched over `git` should authenticate with SSH
or a git credential helper.
:::
#### `remote.cacert`
- **Type**: `string`
@@ -406,10 +354,6 @@ remote:
trusted-hosts:
- github.com
- gitlab.com
auth:
- host: gitlab.com
headers:
PRIVATE-TOKEN: ${GITLAB_TOKEN}
cacert: ''
cert: ''
cert-key: ''

View File

@@ -171,11 +171,6 @@ includes:
my-remote-namespace: https://{{.TOKEN}}@raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
```
Prefer the [`remote.auth`](./reference/config.md#remote-auth) configuration
option when the server accepts a header. A credential in the URL ends up in
error messages and in the confirmation prompt, and the include can no longer be
committed as-is.
## Special Variables
The file-path [special variables](../docs/reference/templating.md#file-paths)

View File

@@ -300,6 +300,58 @@ task --trusted-hosts github.com,gitlab.com -t https://github.com/user/repo.git//
task --trusted-hosts example.com:8080 -t https://example.com:8080/Taskfile.yml
```
#### `remote.auth`
- **Type**: `array of objects`
- **Default**: `[]` (empty list)
- **Description**: HTTP headers to send when downloading a remote Taskfile from
a given host
```yaml
remote:
auth:
- host: gitlab.com
headers:
PRIVATE-TOKEN: ${GITLAB_TOKEN}
- host: artifacts.example.com:8443
headers:
Authorization: Bearer ${ARTIFACTS_TOKEN}
```
This is the recommended way to authenticate a remote Taskfile. Unlike a
credential placed in the URL, the header never appears in your Taskfile, in the
confirmation prompt or in an error message, so the include URL stays safe to
commit.
Each entry applies to a single host, matched exactly and including the port if
the URL has one — the same rule as
[`remote.trusted-hosts`](#remote-trusted-hosts). Header values may reference
environment variables with `${VAR}` or `$VAR`, read when Task contacts the host.
An undefined variable expands to nothing, so the header is sent empty and the
server rejects it — prefer an environment variable over a literal value, which
cannot contain a `$` followed by a name.
The header your server expects depends on the service:
| Service | Header |
| ----------- | -------------------------------------- |
| GitLab API | `PRIVATE-TOKEN` (or `JOB-TOKEN` in CI) |
| GitHub API | `Authorization: Bearer <token>` |
| Artifactory | `X-JFrog-Art-Api` |
There is no CLI flag or environment variable for this option: a token given on
the command line would be visible to any process listing it.
::: warning
Headers are only sent to the host they are configured for. If that host answers
with a redirect to another one, the request follows the redirect **without**
them, and will likely fail — point the URL at the final host instead. Headers
are also HTTP-only: a Taskfile fetched over `git` should authenticate with SSH
or a git credential helper.
:::
#### `remote.cacert`
- **Type**: `string`
@@ -354,6 +406,10 @@ remote:
trusted-hosts:
- github.com
- gitlab.com
auth:
- host: gitlab.com
headers:
PRIVATE-TOKEN: ${GITLAB_TOKEN}
cacert: ''
cert: ''
cert-key: ''

View File

@@ -171,6 +171,11 @@ includes:
my-remote-namespace: https://{{.TOKEN}}@raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
```
Prefer the [`remote.auth`](./reference/config.md#remote-auth) configuration
option when the server accepts a header. A credential in the URL ends up in
error messages and in the confirmation prompt, and the include can no longer be
committed as-is.
## Special Variables
The file-path [special variables](../docs/reference/templating.md#file-paths)