feat: introduce secret URLs to runner configuration #1383

Merged

mfenniak merged 1 commit from aahlenst/runner:secret-urls into main 2026-02-19 00:27:11 +00:00

Conversation 12 Commits 1 Files changed 3 +342 -8

aahlenst commented 2026-02-17 11:54:43 +00:00

Member

Copy link

Introduce secret URLs to the runner configuration. They enable loading secrets from files.

cache.secret and server.connections.<name>.token each got a companion field: cache.secret_url and server.connections.<name>.token_url, respectively. They are mutually exclusive. For example, if cache.secret and cache.secret_url are both present, then Forgejo Runner will exit with an error.

Shortened example configuration:

cache:
  secret_url: file:cache-secret.txt
server:
  connections:
    example:
      url: https://example.com/
      uuid: 7f7695df-a064-4c70-a597-56714e851e2c
      token_url: file:$CREDENTIALS_DIRECTORY/token.txt
      labels:
        - debian:docker://node:24-trixie

file: URLs can optionally include a single placeholder: $CREDENTIALS_DIRECTORY. If an environment variable CREDENTIALS_DIRECTORY can be found, $CREDENTIALS_DIRECTORY will be replaced by its value. If no environment variable CREDENTIALS_DIRECTORY is present, $CREDENTIALS_DIRECTORY will not be replaced.

Example unit file that demonstrates integration with systemd Credentials:

[Unit]
Description=Forgejo Runner
After=syslog.target network.target

[Service]
User=runner
Group=runner
Type=exec
ExecStart=/usr/local/bin/forgejo-runner \
    --config=/etc/forgejo-runner/config.yml \
    daemon
LoadCredential=runner-token:/etc/forgejo-runner/secrets/token.txt
WorkingDirectory=/home/runner

[Install]
WantedBy=multi-user.target

Corresponding config.yml:

server:
  connections:
    example:
      url: https://example.com/
      uuid: 7f7695df-a064-4c70-a597-56714e851e2c
      token_url: file:$CREDENTIALS_DIRECTORY/runner-token
      labels:
        - debian:docker://node:24-trixie

See forgejo/forgejo-actions-feature-requests#88 for motivation and background.

• features
  • PR: feat: introduce secret URLs to runner configuration

Introduce secret URLs to the runner configuration. They enable loading secrets from files. `cache.secret` and `server.connections.<name>.token` each got a companion field: `cache.secret_url` and `server.connections.<name>.token_url`, respectively. They are mutually exclusive. For example, if `cache.secret` and `cache.secret_url` are both present, then Forgejo Runner will exit with an error. Shortened example configuration: ```yaml cache: secret_url: file:cache-secret.txt server: connections: example: url: https://example.com/ uuid: 7f7695df-a064-4c70-a597-56714e851e2c token_url: file:$CREDENTIALS_DIRECTORY/token.txt labels: - debian:docker://node:24-trixie ``` `file:` URLs can optionally include a single placeholder: `$CREDENTIALS_DIRECTORY`. If an environment variable `CREDENTIALS_DIRECTORY` can be found, `$CREDENTIALS_DIRECTORY` will be replaced by its value. If no environment variable `CREDENTIALS_DIRECTORY` is present, `$CREDENTIALS_DIRECTORY` will not be replaced. Example unit file that demonstrates integration with [systemd Credentials](https://systemd.io/CREDENTIALS/): ``` [Unit] Description=Forgejo Runner After=syslog.target network.target [Service] User=runner Group=runner Type=exec ExecStart=/usr/local/bin/forgejo-runner \ --config=/etc/forgejo-runner/config.yml \ daemon LoadCredential=runner-token:/etc/forgejo-runner/secrets/token.txt WorkingDirectory=/home/runner [Install] WantedBy=multi-user.target ``` Corresponding config.yml: ``` server: connections: example: url: https://example.com/ uuid: 7f7695df-a064-4c70-a597-56714e851e2c token_url: file:$CREDENTIALS_DIRECTORY/runner-token labels: - debian:docker://node:24-trixie ``` See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/88 for motivation and background. <!--start release-notes-assistant--> <!--URL:https://code.forgejo.org/forgejo/runner--> - features - [PR](https://code.forgejo.org/forgejo/runner/pulls/1383): <!--number 1383 --><!--line 0 --><!--description ZmVhdDogaW50cm9kdWNlIHNlY3JldCBVUkxzIHRvIHJ1bm5lciBjb25maWd1cmF0aW9u-->feat: introduce secret URLs to runner configuration<!--description--> <!--end release-notes-assistant-->

❤️ 2 🚀 2

aahlenst added 1 commit 2026-02-17 11:54:44 +00:00

feat: optionally import secrets from files 9adc3c5e13

aahlenst commented 2026-02-17 11:56:08 +00:00

Author

Member

Copy link

I'm not 100% sure about secret:. The alternative would be to interpret everything without a scheme as plain secret. On the other hand, I don't think that ambiguities are good.

cc @viceice: Hope the feature works for you. 😄

I'm not 100% sure about `secret:`. The alternative would be to interpret everything without a scheme as plain secret. On the other hand, I don't think that ambiguities are good. cc @viceice: Hope the feature works for you. 😄

❤️ 1 🎉 1 🚀 1

aahlenst added the

Kind/Enhancement

label 2026-02-17 13:19:10 +00:00

mfenniak commented 2026-02-17 17:10:21 +00:00

Owner

Copy link

I don't love secret:....

• It invokes an instinct that I'm looking at an encrypted value of some kind, not a plain-text value that is supposed to be secret but it is sitting right in front of me.
• It isn't a standard URL format, and so it doesn't help a user by having any existing knowledge of what this means and how it should be used.

If we wanted to make these values consistently "always URLs", then it would imply to me that they should be data:... as that's a well-known URL scheme with inline data. However, it's obviously ugly here -- data:,some-secret-value, or data:text/plain,some-secret-value would be the standardized format, and then characters need to be percent-encoded or base64 encoded (data:text/plain;base64,...).

I'd prefer just omitting the URL scheme. secret: confuses more than it clarifies (to me), and data: isn't very usable for manual entry.

I don't love `secret:...`. - It invokes an instinct that I'm looking at an encrypted value of some kind, not a plain-text value that is supposed to be secret but it is sitting right in front of me. - It isn't a standard URL format, and so it doesn't help a user by having any existing knowledge of what this means and how it should be used. If we wanted to make these values consistently "always URLs", then it would imply to me that they should be `data:...` as that's a well-known URL scheme with inline data. However, it's obviously ugly here -- `data:,some-secret-value`, or `data:text/plain,some-secret-value` would be the standardized format, and then characters need to be percent-encoded or base64 encoded (`data:text/plain;base64,...`). I'd prefer just omitting the URL scheme. `secret:` confuses more than it clarifies (to me), and `data:` isn't very usable for manual entry.

mfenniak commented 2026-02-17 17:11:36 +00:00

Owner

Copy link

I'm also confused about the usage of file: -- it doesn't seem consistent with standard expectations of a file URL. A file URL has a host component that can be omitted. I'd expect file:///$CREDENTIALS_DIRECTORY/runner-token, not file:$CREDENTIALS_DIRECTORY/runner-token?

I'm also confused about the usage of `file:` -- it doesn't seem consistent with standard expectations of a file URL. A file URL has a host component that can be omitted. I'd expect `file:///$CREDENTIALS_DIRECTORY/runner-token`, not `file:$CREDENTIALS_DIRECTORY/runner-token`?

👍 1

aahlenst commented 2026-02-17 19:14:21 +00:00

Author

Member

Copy link

@mfenniak wrote in #1383 (comment):

I'd prefer just omitting the URL scheme. secret: confuses more than it clarifies (to me), and data: isn't very usable for manual entry.

I'm happy to ditch secret:. The question then is: what's the alternative? Please see forgejo/forgejo-actions-feature-requests#88 (comment) for the existing proposals.

I'm also confused about the usage of file: -- it doesn't seem consistent with standard expectations of a file URL. A file URL has a host component that can be omitted. I'd expect file:///$CREDENTIALS_DIRECTORY/runner-token, not file:$CREDENTIALS_DIRECTORY/runner-token

Note that I am talking about URIs (i at the end), not URLs (l at the end). I haven't studied URLs, so I don't know whether there are differences.

I looked into https://www.rfc-editor.org/rfc/rfc3986#section-1.1.1 and https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax. It looks like the authority is optional. The first two slashes are only required when there is an authority. Therefore, file:/my/path/here is valid as would by file:hello-there.txt. The tests cover both cases. url.Parse() seems to agree.

Now, I interpret this as another indication that using URIs is not a good idea at all. You're confused, I had to read RFCs and paused when typing secret: secret:verysecret.

That would leave us with separate variables:

cache:
  secret_file: /path/to/secret.txt
server:
  connections:
    example:
      url: https://example.com/
      uuid: 7f7695df-a064-4c70-a597-56714e851e2c
      token_file: $CREDENTIALS_DIRECTORY/runner-token
      labels:
        - debian:docker://node:24-trixie

cache.secret and server.connections.<name>.token would work as before.

What should the behaviour be if both are present? I'd raise an error instead of introducing precedence rules that are hard to discover.

@mfenniak wrote in https://code.forgejo.org/forgejo/runner/pulls/1383#issuecomment-78291: > I'd prefer just omitting the URL scheme. `secret:` confuses more than it clarifies (to me), and `data:` isn't very usable for manual entry. I'm happy to ditch `secret:`. The question then is: what's the alternative? Please see https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/88#issuecomment-77908 for the existing proposals. > I'm also confused about the usage of `file:` -- it doesn't seem consistent with standard expectations of a file URL. A file URL has a host component that can be omitted. I'd expect `file:///$CREDENTIALS_DIRECTORY/runner-token`, not `file:$CREDENTIALS_DIRECTORY/runner-token` Note that I am talking about URIs (i at the end), not URLs (l at the end). I haven't studied URLs, so I don't know whether there are differences. I looked into https://www.rfc-editor.org/rfc/rfc3986#section-1.1.1 and https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax. It looks like the authority is optional. The first two slashes are only required when there is an authority. Therefore, `file:/my/path/here` is valid as would by `file:hello-there.txt`. The tests cover both cases. `url.Parse()` seems to agree. Now, I interpret this as another indication that using URIs is not a good idea *at all*. You're confused, I had to read RFCs and paused when typing `secret: secret:verysecret`. That would leave us with separate variables: ```yaml cache: secret_file: /path/to/secret.txt server: connections: example: url: https://example.com/ uuid: 7f7695df-a064-4c70-a597-56714e851e2c token_file: $CREDENTIALS_DIRECTORY/runner-token labels: - debian:docker://node:24-trixie ``` `cache.secret` and `server.connections.<name>.token` would work as before. What should the behaviour be if both are present? I'd raise an error instead of introducing precedence rules that are hard to discover.

mfenniak commented 2026-02-17 20:40:57 +00:00

Owner

Copy link

You're correct, the authority section of the file URL is optional.

Multiple fields (secret and secret_file) may be equally good when there are two options, but I think if we have any future desire to expand this it becomes very messy. 🤔 I'm imagining supporting a remote secret store (AWS SAM, Vault, etc.), and having three or more options.

What if the two fields were secret and secret_url? This meets a couple goals:

• No need for the code to guess whether it's a URL or a plaintext value
• It's clear when reading the config file which fields in the configuration can take a URL, as someone could easily believe the magic URL behaviour applies to every field without some separation
• If more approaches for resolving the value are added, for example reading the value from a remote secret store, it could be added to handling for secret_url cleanly

cache:
  secret_url: file:///path/to/secret.txt
server:
  connections:
    example:
      # ...
      token: plaintext-token

Or alternatively... we add the URL capability as a child field?

cache:
  secret:
    url: file:///path/to/secret.txt
server:
  connections:
    example:
      # ...
      token: plaintext-token

---

$CREDENTIALS_DIRECTORY is also going to raise a separate design question. It makes it look to a user that environment variables can be used, but only a single one is supported. 🤔 I think this is probably fine but wonder if there's anything we can do to minimize user confusion.

You're correct, the authority section of the file URL is optional. Multiple fields (`secret` and `secret_file`) may be equally good when there are two options, but I think if we have any future desire to expand this it becomes very messy. 🤔 I'm imagining supporting a remote secret store (AWS SAM, Vault, etc.), and having three or more options. What if the two fields were `secret` and `secret_url`? This meets a couple goals: - No need for the code to guess whether it's a URL or a plaintext value - It's clear when reading the config file which fields in the configuration can take a URL, as someone could easily believe the magic URL behaviour applies to every field without some separation - If more approaches for resolving the value are added, for example reading the value from a remote secret store, it could be added to handling for `secret_url` cleanly ```yaml cache: secret_url: file:///path/to/secret.txt server: connections: example: # ... token: plaintext-token ``` Or alternatively... we add the URL capability as a child field? ```yaml cache: secret: url: file:///path/to/secret.txt server: connections: example: # ... token: plaintext-token ``` --- `$CREDENTIALS_DIRECTORY` is also going to raise a separate design question. It makes it look to a user that environment variables can be used, but only a single one is supported. 🤔 I think this is probably fine but wonder if there's anything we can do to minimize user confusion.

aahlenst commented 2026-02-17 21:41:14 +00:00

Author

Member

Copy link

@mfenniak wrote in #1383 (comment):

If more approaches for resolving the value are added, for example reading the value from a remote secret store, it could be added to handling for secret_url cleanly

I find future-proofing difficult, especially if I don't know anything about integrating secret stores like Vault. If you think it's a good idea, then I'm fine with using secret_url.

Or alternatively... we add the URL capability as a child field?

I'd like to reserve that option for a potential introduction of secret stores.

$CREDENTIALS_DIRECTORY is also going to raise a separate design question. It makes it look to a user that environment variables can be used, but only a single one is supported. 🤔 I think this is probably fine but wonder if there's anything we can do to minimize user confusion.

%credentials_directory? Ultimately, there's only so much we can do.

@mfenniak wrote in https://code.forgejo.org/forgejo/runner/pulls/1383#issuecomment-78297: > If more approaches for resolving the value are added, for example reading the value from a remote secret store, it could be added to handling for `secret_url` cleanly I find future-proofing difficult, especially if I don't know anything about integrating secret stores like Vault. If you think it's a good idea, then I'm fine with using `secret_url`. > Or alternatively... we add the URL capability as a child field? I'd like to reserve that option for a potential introduction of secret stores. > `$CREDENTIALS_DIRECTORY` is also going to raise a separate design question. It makes it look to a user that environment variables can be used, but only a single one is supported. :thinking: I think this is probably fine but wonder if there's anything we can do to minimize user confusion. `%credentials_directory`? Ultimately, there's only so much we can do.

mfenniak commented 2026-02-18 01:28:48 +00:00

Owner

Copy link

secret_url & token_url as a separate field, with an error if both are provided. 👍

$CREDENTIALS_DIRECTORY as currently implemented. 👍

`secret_url` & `token_url` as a separate field, with an error if both are provided. 👍 `$CREDENTIALS_DIRECTORY` as currently implemented. 👍

aahlenst force-pushed secret-urls from 9adc3c5e13 to 8103b426c7 2026-02-18 13:51:10 +00:00 Compare

aahlenst commented 2026-02-18 13:56:44 +00:00

Author

Member

Copy link

I went with secret_uri instead of secret_url to be extra specific before somebody thinks they can use something like secret_url: https://example.com/path/to/secret.txt. Otherwise, it should behave as discussed.

I updated the PR description and forgejo-runner generate-config accordingly. Each stresses that $CREDENTIALS_DIRECTORY is a placeholder and that it is the only supported placeholder.

I went with `secret_uri` instead of `secret_url` to be extra specific before somebody thinks they can use something like `secret_url: https://example.com/path/to/secret.txt`. Otherwise, it should behave as discussed. I updated the PR description and `forgejo-runner generate-config` accordingly. Each stresses that `$CREDENTIALS_DIRECTORY` is a placeholder and that it is the only supported placeholder.

mfenniak commented 2026-02-18 15:46:32 +00:00

Owner

Copy link

@aahlenst wrote in #1383 (comment):

I went with secret_uri instead of secret_url to be extra specific before somebody thinks they can use something like secret_url: https://example.com/path/to/secret.txt. Otherwise, it should behave as discussed.

I don't think we share the same understanding of the difference between a URI and a URL. I'll describe my understanding:

URIs are the vaguest of the uniform resource things. They provide a unique identifier for a resource. URIs can be references that aren't functional to locate a resource, but just identify it; like urn:oasis:names:specification:docbook:dtd:xml:4.1.2.

URLs are are subset of URIs, which provide a scheme that can be used to locate a resource, hence they are uniform resource locators.

By making secret_uri:

• Functionally: people will just typo it because it's unexpected
• Technically: you're expanding the scope of values from URL to URI, and there's no reason we would ever accept values here that aren't usable as resource locators
• https://example.com/path/to/secret.txt is both a URI and a URL, and so if you're concerned about people misunderstanding that it can be used here, that misunderstanding still exists

If we're in a disagreement here, let's get a third opinion involved.

@aahlenst wrote in https://code.forgejo.org/forgejo/runner/pulls/1383#issuecomment-78394: > I went with `secret_uri` instead of `secret_url` to be extra specific before somebody thinks they can use something like `secret_url: https://example.com/path/to/secret.txt`. Otherwise, it should behave as discussed. I don't think we share the same understanding of the difference between a URI and a URL. I'll describe my understanding: URIs are the vaguest of the uniform resource things. They provide a unique identifier for a resource. URIs can be references that aren't functional to locate a resource, but just identify it; like `urn:oasis:names:specification:docbook:dtd:xml:4.1.2`. URLs are are subset of URIs, which provide a scheme that can be used to locate a resource, hence they are uniform resource locators. By making `secret_uri`: - Functionally: people will just typo it because it's unexpected - Technically: you're expanding the scope of values from URL to URI, and there's no reason we would ever accept values here that aren't usable as resource locators - `https://example.com/path/to/secret.txt` is both a URI and a URL, and so if you're concerned about people misunderstanding that it can be used here, that misunderstanding still exists If we're in a disagreement here, let's get a third opinion involved.

mfenniak referenced this pull request 2026-02-18 15:48:24 +00:00

feat: allow config server.connections config to poll multiple Forgejo servers simultaneously #1380

aahlenst force-pushed secret-urls from 8103b426c7 to c4617fd1e0 2026-02-18 16:16:26 +00:00 Compare

aahlenst force-pushed secret-urls from c4617fd1e0 to 37d3688d5a 2026-02-18 16:17:54 +00:00 Compare

aahlenst changed title from feat: introduce secret URIs to runner configuration to feat: introduce secret URLs to runner configuration 2026-02-18 16:18:04 +00:00

aahlenst commented 2026-02-18 16:21:56 +00:00

Author

Member

Copy link

@mfenniak wrote in #1383 (comment):

If we're in a disagreement here, let's get a third opinion involved.

I don't think that is has to come to this. 😆

PR updated, description updated, commit message updated.

@mfenniak wrote in https://code.forgejo.org/forgejo/runner/pulls/1383#issuecomment-78395: > If we're in a disagreement here, let's get a third opinion involved. I don't think that is has to come to this. 😆 PR updated, description updated, commit message updated.

mfenniak approved these changes 2026-02-18 22:56:49 +00:00

mfenniak added the

run-end-to-end-tests

label 2026-02-18 22:56:54 +00:00

cascading-pr referenced this pull request from actions/setup-forgejo 2026-02-18 22:57:05 +00:00

cascading-pr from https://code.forgejo.org/forgejo/runner refs/pull/1383/head to forgejo/runner-1383 #892

cascading-pr commented 2026-02-18 22:57:06 +00:00

Contributor

Copy link

cascading-pr updated at actions/setup-forgejo#892

cascading-pr updated at https://code.forgejo.org/actions/setup-forgejo/pulls/892

mfenniak merged commit 460bc800ac into main 2026-02-19 00:27:11 +00:00

mfenniak referenced this pull request from a commit 2026-02-19 00:27:11 +00:00

feat: introduce secret URLs to runner configuration (#1383)

viceice-bot referenced this pull request from actions/setup-forgejo 2026-02-19 01:36:13 +00:00

Update dependency forgejo/runner to v12.7.0 #896

mfenniak referenced this pull request from a commit 2026-02-19 03:00:43 +00:00

Update dependency forgejo/runner to v12.7.0 (#896)

forgejo-mirror referenced this pull request from a commit 2026-02-19 04:01:08 +00:00

Update module code.forgejo.org/forgejo/runner/v12 to v12.7.0 (forgejo) (#11363)

viceice-bot referenced this pull request 2026-02-20 20:19:16 +00:00

Update forgejo-runner to v12.7.0 #1394

Sign in to join this conversation.

Reviewers

No reviewers

mfenniak

Labels

Clear labels   

FreeBSD

  

Kind/Breaking

Breaking change that won't be backward compatible

  

Kind/Bug

Something is not working

  

Kind/Chore

It is no fun but it needs to be done, this is a chore.

  

Kind/DependencyUpdate

for pull requests that are created by renovate when updating a dependency

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

  

Windows

Windows ports is an independent project, see https://github.com/Crown0815/Forgejo-runner-windows-builder

  

linux-powerpc64le

powerpc64le

  

linux-riscv64

  

linux-s390x

  

run-end-to-end-tests

Run https://code.forgejo.org/forgejo/end-to-end with a runner compiled from this pull request

  

run-forgejo-tests

Run https://codeberg.org/forgejo/forgejo tests importing the runner from this pull request

No labels

FreeBSD

Kind/Breaking

Kind/Bug

Kind/Chore

Kind/DependencyUpdate

Kind/Documentation

Kind/Enhancement

Kind/Feature

Kind/Security

Kind/Testing

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

Windows

linux-powerpc64le

linux-riscv64

linux-s390x

run-end-to-end-tests

run-forgejo-tests

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

forgejo/runner!1383

No description provided.