forgejo/runner
31
87
Fork 91
Code Issues 38 Pull requests 9 Releases 81 Packages 1 Activity Actions

refactor: separate Config from on-disk format #1377

Merged
mfenniak merged 1 commit from aahlenst/runner:config-refactor into main 2026-02-16 02:50:07 +00:00
Conversation 6 Commits 1 Files changed 10 +1047 -152
aahlenst commented 2026-02-15 15:01:54 +00:00
Member
Copy link

Separate Config from the on-disk format. That has multiple advantages:

  • It is easier to test and validate.
  • Config is easier to change. Fields retained for backwards compatibility do no longer have to be carried around.
  • Transformations like turning file:///path/to/secret into the actual secret value (not implemented yet) can be performed while constructing Config and cached. No separate fields are necessary.
  • Pointers like *bool do no longer have to be carried around.

New(), which replaces LoadDefault(), offers functional options. New() produces the default configuration without requiring gymnastics with empty file names. To overlay the default configuration with a (partial) configuration from a YAML configuration file, use New(FromFile("/path/to/config.yaml")).

The refactoring is designed to have minimal impact on existing code and tests. It is supposed to be fully backwards-compatible. The only user-facing change is the emission of warnings if invalid configuration values are encountered. Previously, those were silently ignored.

  • other
    • PR: refactor: separate Config from on-disk format
Separate `Config` from the on-disk format. That has multiple advantages: * It is easier to test and validate. * `Config` is easier to change. Fields retained for backwards compatibility do no longer have to be carried around. * Transformations like turning `file:///path/to/secret` into the actual secret value (not implemented yet) can be performed while constructing `Config` and cached. No separate fields are necessary. * Pointers like `*bool` do no longer have to be carried around. `New()`, which replaces `LoadDefault()`, offers functional options. `New()` produces the default configuration without requiring gymnastics with empty file names. To overlay the default configuration with a (partial) configuration from a YAML configuration file, use `New(FromFile("/path/to/config.yaml"))`. The refactoring is designed to have minimal impact on existing code and tests. It is supposed to be fully backwards-compatible. The only user-facing change is the emission of warnings if invalid configuration values are encountered. Previously, those were silently ignored. <!--start release-notes-assistant--> <!--URL:https://code.forgejo.org/forgejo/runner--> - other - [PR](https://code.forgejo.org/forgejo/runner/pulls/1377): <!--number 1377 --><!--line 0 --><!--description cmVmYWN0b3I6IHNlcGFyYXRlIENvbmZpZyBmcm9tIG9uLWRpc2sgZm9ybWF0-->refactor: separate Config from on-disk format<!--description--> <!--end release-notes-assistant-->
refactor: separate Config from on-disk format
All checks were successful
checks / validate pre-commit-hooks file (pull_request) Successful in 37s
Details
checks / Build Forgejo Runner (pull_request) Successful in 43s
Details
checks / validate mocks (pull_request) Successful in 46s
Details
checks / Build unsupported platforms (pull_request) Successful in 20s
Details
checks / runner exec tests (pull_request) Successful in 34s
Details
checks / integration tests (docker-latest) (pull_request) Successful in 8m17s
Details
checks / integration tests (docker-stable) (pull_request) Successful in 10m35s
Details
issue-labels / release-notes (pull_request_target) Successful in 6s
Details
cascade / debug (pull_request_target) Has been skipped
Details
cascade / end-to-end (pull_request_target) Successful in 7s
Details
cascade / forgejo (pull_request_target) Successful in 1m41s
Details
ebb0c4f52a
aahlenst commented 2026-02-15 15:04:08 +00:00
Author
Member
Copy link

Notes/Questions:

  • I am not sure about the naming. I find Host, Container etc. weird because Host is not a host, but configuration for the host. I'd prefer HostSettings or HostConfiguration or something like that (to be changed in a separate PR). However, if Host should stay long-term, then it would probably make sense to rename serializedHostSettings to serializedHost.
  • Do we want to turn warnings into errors in the future? If so, the warnings need to be changed.
  • In some cases, it's hard to figure out what the user intended due to Go's handling of zero values. I refrained from turning almost every setting into a pointer.
Notes/Questions: * I am not sure about the naming. I find `Host`, `Container` etc. weird because `Host` is not a host, but configuration for the host. I'd prefer `HostSettings` or `HostConfiguration` or something like that (to be changed in a separate PR). However, if `Host` should stay long-term, then it would probably make sense to rename `serializedHostSettings` to `serializedHost`. * Do we want to turn warnings into errors in the future? If so, the warnings need to be changed. * In some cases, it's hard to figure out what the user intended due to Go's handling of zero values. I refrained from turning almost every setting into a pointer.
mfenniak approved these changes 2026-02-16 02:13:44 +00:00
cascading-pr commented 2026-02-16 02:14:06 +00:00
Contributor
Copy link

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

cascading-pr updated at https://code.forgejo.org/actions/setup-forgejo/pulls/887
mfenniak commented 2026-02-16 02:21:12 +00:00
Owner
Copy link

@aahlenst wrote in #1377 (comment):

  • I am not sure about the naming. I find Host, Container etc. weird because Host is not a host, but configuration for the host. I'd prefer HostSettings or HostConfiguration or something like that (to be changed in a separate PR). However, if Host should stay long-term, then it would probably make sense to rename serializedHostSettings to serializedHost.

The name is a little awkward, I agree. There's so little in there... workdir_parent... I'd argue it probably belongs more in the runner section, eliminating the naming problem? But in a separate refactoring PR.

  • Do we want to turn warnings into errors in the future? If so, the warnings need to be changed.

These warnings don't induce a lot of fear in me like a user is going to be trying to configure one thing, and getting something drastically different with dangerous outcomes. I think they're fine as warnings.

  • In some cases, it's hard to figure out what the user intended due to Go's handling of zero values. I refrained from turning almost every setting into a pointer.

Indeed; not my favourite part of Go. The interpretations you've made make sense to me, but there are a lot of affected settings where they're unconditionally read from the deserialized data. I think it is correct at this time, at least.

@aahlenst wrote in https://code.forgejo.org/forgejo/runner/pulls/1377#issuecomment-78071: > * I am not sure about the naming. I find `Host`, `Container` etc. weird because `Host` is not a host, but configuration for the host. I'd prefer `HostSettings` or `HostConfiguration` or something like that (to be changed in a separate PR). However, if `Host` should stay long-term, then it would probably make sense to rename `serializedHostSettings` to `serializedHost`. The name is a little awkward, I agree. There's so little in there... `workdir_parent`... I'd argue it probably belongs more in the `runner` section, eliminating the naming problem? But in a separate refactoring PR. > * Do we want to turn warnings into errors in the future? If so, the warnings need to be changed. These warnings don't induce a lot of fear in me like a user is going to be trying to configure one thing, and getting something drastically different with dangerous outcomes. I think they're fine as warnings. > * In some cases, it's hard to figure out what the user intended due to Go's handling of zero values. I refrained from turning almost every setting into a pointer. Indeed; not my favourite part of Go. The interpretations you've made make sense to me, but there are a lot of affected settings where they're unconditionally read from the deserialized data. I think it is correct at this time, at least.
mfenniak commented 2026-02-16 03:28:28 +00:00
Owner
Copy link

@aahlenst Minor issue, report_retry section reports warnings if absent from the config file:

WARN[0000] Ignoring invalid `runner.report_retry.max_retries`: '\x00'
WARN[0000] Ignoring invalid `runner.report_retry.initial_delay`: '\x00'
@aahlenst Minor issue, `report_retry` section reports warnings if absent from the config file: ``` WARN[0000] Ignoring invalid `runner.report_retry.max_retries`: '\x00' WARN[0000] Ignoring invalid `runner.report_retry.initial_delay`: '\x00' ```
aahlenst commented 2026-02-16 12:50:20 +00:00
Author
Member
Copy link

@mfenniak wrote in #1377 (comment):

The name is a little awkward, I agree. There's so little in there... workdir_parent... I'd argue it probably belongs more in the runner section, eliminating the naming problem? But in a separate refactoring PR.

It's not only Host, but all of them. config.Container isn't a container either. What about renaming the types to HostSettings, ContainerSettings?

Indeed; not my favourite part of Go. The interpretations you've made make sense to me, but there are a lot of affected settings where they're unconditionally read from the deserialized data. I think it is correct at this time, at least.

Happy to fix if we encounter problems. It should get better with Go 1.26 once we upgrade.

PR to silence the unnecessary warnings is up: #1381

@mfenniak wrote in https://code.forgejo.org/forgejo/runner/pulls/1377#issuecomment-78104: > The name is a little awkward, I agree. There's so little in there... `workdir_parent`... I'd argue it probably belongs more in the `runner` section, eliminating the naming problem? But in a separate refactoring PR. It's not only `Host`, but all of them. `config.Container` isn't a container either. What about renaming the types to `HostSettings`, `ContainerSettings`? > Indeed; not my favourite part of Go. The interpretations you've made make sense to me, but there are a lot of affected settings where they're unconditionally read from the deserialized data. I think it is correct at this time, at least. Happy to fix if we encounter problems. It should [get better](https://go.dev/doc/go1.26#language) with Go 1.26 once we upgrade. PR to silence the unnecessary warnings is up: https://code.forgejo.org/forgejo/runner/pulls/1381
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
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!1377
No description provided.