The runner only runs a step's post stage if the step *actually* ran. A composite step that was skipped because its `if:` was false, or that never ran because an earlier step failed, has no post stage. Its nested actions were checked out anyway, and nothing ever removes them. Every such job leaves a few working copies behind on the runner's disk, forever. A restart does not clean them up either.
Co-authored-by: perfectra1n <jonfuller2012@gmail.com>
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1732
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
In testing of 5 popular action repos, this change uses 100x less disk space for the actions repo cache and makes initial repo cloning 12x faster. It does this by only fetching 1 commit and 0-1 refs from the remote whereas current `main` code unconditionally fetches all refs including tags, branches and the full commit history associated with each ref and any other reachable objects.
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1722
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Adds a new `ParseOption` to the jobparser: `EnableNamespaces()`. When enabled, reusable workflows will not use "dot-qualified" job names (`outer.inner`), but instead will have an concept of a namespace associated with each job identifier.
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1716
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [data.forgejo.org/oci/ci](https://code.forgejo.org/forgejo/ci-image-builder) | container | major | `2` → `3` |
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
- Automerge
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4zOS4zIiwidXBkYXRlZEluVmVyIjoiNDQuMzkuMyIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiS2luZC9EZXBlbmRlbmN5VXBkYXRlIiwicnVuLWVuZC10by1lbmQtdGVzdHMiXX0=-->
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1712
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Fixes#1678. Rather than returning a stream of chunks that may have stdout/stderr data, and may have an exit code, and may have an error message, separates them into three different messages and uses protobuf's `oneof` message type to allow one-and-only-one to be streamed at a time.
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1705
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
Fixes#1679.
Rather than specifying `env` and `working_dir` in both the `CreateRequest` and `ExecRequest`, the runner will provide the complete information in the `ExecRequest`. This simplifies a plugin author's job by providing just have one source of this information when executing commands.
Separate from the mock testing performed here, I've integration tested this with workflow-level, job-level, and step-level environment variables, and confirmed that they are all set and override each other as expected.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1686): <!--number 1686 --><!--line 0 --><!--description Zml4OiByZW1vdmUgZHVwbGljYXRlIHdvcmtpbmcgZGlyZWN0b3J5ICYgZW52aXJvbm1lbnQgZnJvbSBwbHVnaW4gcHJvdG9jb2w=-->fix: remove duplicate working directory & environment from plugin protocol<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1686
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
A coding error seems to have assumed that `assert.Error(t, err, j.errorMessage)` would check that the error message is contained in err, but this just asserts that there is an error. Fix that assertion so that tests with a `errorMessage` field will fail if they don't get an error, and fail if they get an error that doesn't contain the target error message.
Discovered while making a mistake in implementing a test in #1691.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1693): <!--number 1693 --><!--line 0 --><!--description dGVzdDogZml4IGBUZXN0UnVubmVyX1J1bkV2ZW50YCBub3QgY2hlY2tpbmcgZXJyb3IgbWVzc2FnZXMgb24gZXJyb3IgY2FzZXM=-->test: fix `TestRunner_RunEvent` not checking error messages on error cases<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1693
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
When running docker-based jobs, runner would determine whether to attach a tty to the entrypoint, and each `exec`'d command, by whether the runner's own stdout was a tty. This behaviour is removed in this PR.
This behaviour doesn't make much sense. When running as a daemon, job information is not logged to stdout and so the state of stdout is irrelevant. When running in `forgejo-runner exec`, the behaviour doesn't take into account the usage of the `-json` parameter (which logs in JSON), and the fact that the log output is embedded with log lines that describe each job that is being executed -- for both reasons, the job doesn't really have a terminal to control. It also isn't great for `daemon` and `exec` to behave differently inside the jobs.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1691): <!--number 1691 --><!--line 0 --><!--description Zml4OiBwcmV2ZW50IHJ1bm5lcidzIHN0ZG91dCBpc2F0dHkgYWZmZWN0aW5nIGRvY2tlciBjcmVhdGUsIGV4ZWMsIGF0dGFjaCBjb21tYW5kcw==-->fix: prevent runner's stdout isatty affecting docker create, exec, attach commands<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1691
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
All LXC and host-based commands were being unconditionally run with a pty attached. As Forgejo Action's log viewer is not a terminal emulator, and it is not capable of supporting most terminal control output, this PR removes that implementation choice. This brings consistency with docker-based execution, where the container may optionally be connected to a tty, but the command execution is not (when using `daemon` mode).
The accurate state to describe Forgejo Runner's output is that it is not a terminal, but that it does support a subset of ANSI codes such as colour selection (FG & BG), bold, faint, italic, underline, and hyperlinks. Unfortunately there is no way to communicate that subset to a program in a standardized way -- setting a tty is sometimes used as a signal for such, but it's a near-miss in communicating that intent.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1692): <!--number 1692 --><!--line 0 --><!--description Zml4OiBkb24ndCBydW4gaG9zdC1iYXNlZCBleGVjdXRvciAmIExYQyBleGVjdXRvciBzdWJjb21tYW5kcyBpbiBhIFRUWQ==-->fix: don't run host-based executor & LXC executor subcommands in a TTY<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1692
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
Implements an experimental gRPC protocol for plugable backend systems, per https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/107#issuecomment-85284.
---
(Notes from @mfenniak, Forgejo merger):
Implements an experimental gRPC protocol for plugable backend systems, per https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/107#issuecomment-85284. This allows future development of new job container execution models, such as Firecracker VMs, qEMU VMs, systemd-nspawn containers, Kubernetes pods, etc.
As an v1alpha protocol, the protocol is subject to change with no stability guarantees at the moment.
As an experimental feature, the Forgejo team is not yet willing to fully commit that this feature will be a permanent addition. We believe it is a good direction, and we believe we can continue to iterate it to a fully supportable and capable feature based upon feedback from ourselves and other users. But as that feedback is collected and incorporated, we leave open the possibility that we may gain new knowledge and be required to change direction.
---
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1500): <!--number 1500 --><!--line 0 --><!--description ZmVhdChwbHVnaW4pOiBhZGQgZXhwZXJpbWVudGFsIGdSUEMgdjFhbHBoYSBwbHVnaW4gYmFja2VuZCBzdXBwb3J0-->feat(plugin): add experimental gRPC v1alpha plugin backend support<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1500
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
The documentation [claims](https://forgejo.org/docs/latest/user/actions/reference/#availability) that context variables can be referenced in `jobs.<job-id>.steps[*].uses`. That is true for normal actions, but not for Docker-based actions. For example, the first step in the workflow below succeeds while the second fails because Forgejo Runner does not interpolate the `uses` key.
```yaml
on:
workflow_dispatch:
inputs:
checkout-tag:
default: 9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0
type: string
debian-tag:
default: stable-slim@sha256:34363c20bd149e41365fc77b086da067ed13ab2dff4cd0612788e12e6d52c44c
type: string
jobs:
run-tag:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@${{ inputs.checkout-tag }}
- uses: docker://docker.io/debian:${{ inputs.debian-tag }}
with:
args: ls -al
```
Resolves https://codeberg.org/forgejo/forgejo/issues/13189.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1656): <!--number 1656 --><!--line 0 --><!--description Zml4OiBpbnRlcnBvbGF0ZSB1c2VzIGtleSBvZiBEb2NrZXIgYWN0aW9ucw==-->fix: interpolate uses key of Docker actions<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1656
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
There are multiple situations where the absence of `runs-on` is correct, for example, if a job references a reusable workflow with `uses`. The logged error only confuses users in those situations. Besides, it is the responsibility of workflow validation to ensure that `runs-on` is present. Therefore, no attempt is made to make the message more accurate.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1655): <!--number 1655 --><!--line 0 --><!--description Zml4OiBkbyBub3QgbG9nIGVycm9yIGlmIHJ1bnMtb24gaXMgYWJzZW50-->fix: do not log error if runs-on is absent<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1655
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Forgejo Runner supports expressions in workflows, for example, `format('Hello {0} {1} {2}', 'Mona', 'the', 'Octocat')`. If Forgejo Runner encounters an invalid expression, it logs an error, but otherwise progresses as if nothing had happened. That can cause unpredictable or even unwanted results. This change turns invalid expressions into a hard error that stops normal execution and fails the respective step.
Resolves https://code.forgejo.org/forgejo/runner/issues/1596.
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1646
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Prevent the usage of `git replace` to create a ref that shadows another commit, similar to previous fixes for tags and branches.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1635): <!--number 1635 --><!--line 0 --><!--description Zml4OiBwcmV2ZW50IGNvbW1pdCBpbXBlcnNvbmF0aW9uIHZpYSBgcmVmcy9yZXBsYWNlLypgIGR1cmluZyBhY3Rpb24gY2hlY2tvdXQ=-->fix: prevent commit impersonation via `refs/replace/*` during action checkout<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1635
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
Update the Docker client libraries from v28 to v29 because v28 is no longer maintained. The minimum requirement for Docker has been raised to Docker 25.0.
Users of Debian 13 (Trixie) or 12 (Bookworm) that use IPv6 [are affected by a bug](https://github.com/moby/moby/pull/49520) in the Docker version shipped by Debian that results in error messages like:
```
2026/07/01 14:58:59 Could not get list of networks: ParseAddr("fd05:d0ca:2::1/112"): unexpected character, want colon (at "/112")
```
Affected Debian users should either not upgrade Forgejo Runner or switch to the Docker package provided by Docker until the problem is either resolved by the Docker or Debian developers.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1547): <!--number 1547 --><!--line 0 --><!--description Y2hvcmU6IHVwZ3JhZGUgZ2l0aHViLmNvbS9kb2NrZXIvY2xpIHRvIHYyOQ==-->chore: upgrade github.com/docker/cli to v29<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1547
Fixes https://codeberg.org/forgejo/forgejo/issues/13503.
The existing implementation of `cancelled()` assumes that it is being invoked in a job execution context, not by the jobparser. Because Forgejo doesn't attempt to check the `if` conditions of jobs during a workflow cancel, I didn't implement this case -- but overlooked that including the function in an expression was still possible if meaningless, and therefore didn't test it.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1633): <!--number 1633 --><!--line 0 --><!--description Zml4OiBuaWwgZGVyZWZlcmVuY2Ugd2hlbiBFdmFsdWF0ZUlmIGlzIGNhbGxlZCB3LyBjYW5jZWxsZWQoKSBleHBy-->fix: nil dereference when EvaluateIf is called w/ cancelled() expr<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1633
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
The workflow command `set-output` allows defining output variables. Unfortunately, it is difficult to use securely. Therefore, it is removed from Forgejo Runner. If workflows still use `set-output`, a warning will be printed. Workflows that want to set output variables can do so by writing to `$FORGEJO_OUTPUT`.
Instead of:
```yaml
- run: |
echo "::set-output name=MY_VARIABLE::value"
```
Use:
```yaml
- run: |
echo "MY_VARIABLE=value" >> "$FORGEJO_OUTPUT"
```
See https://code.forgejo.org/forgejo/runner/issues/1455.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1631): <!--number 1631 --><!--line 0 --><!--description Y2hvcmU6IHJlbW92ZSB3b3JrZmxvdyBjb21tYW5kIHNldC1vdXRwdXQ=-->chore: remove workflow command set-output<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1631
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
The workflow command `set-env` allows injecting additional variables into the environment. Unfortunately, it is difficult to use securely. Therefore, it is removed from Forgejo Runner. If workflows still use `set-env`, a warning will be printed. Contrary to GitHub Actions, it is not possible to restore it by setting the environment variable `ACTIONS_ALLOW_UNSECURE_COMMANDS=true` because better alternatives exist. Workflows that need to amend the environment can write to `$FORGEJO_ENV`.
Instead of:
```yaml
- run: |
echo "::set-env name=MY_VARIABLE::value"
```
Use:
```yaml
- run: |
echo "MY_VARIABLE=value" >> "$FORGEJO_ENV"
```
See https://code.forgejo.org/forgejo/runner/issues/1455.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1627): <!--number 1627 --><!--line 0 --><!--description Y2hvcmU6IHJlbW92ZSB3b3JrZmxvdyBjb21tYW5kIHNldC1lbnY=-->chore: remove workflow command set-env<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1627
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
git subprocesses which the runner spawns were not being placed into a process group, and were not being terminated in a process group, in the event that a job's context was cancelled. This could allow git subprocesses to be left as zombies when git was cancelled by the runner.
This PR fixes the git subprocess management to use the same cross-platform system developed for the host-based executor.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1623): <!--number 1623 --><!--line 0 --><!--description Zml4OiBydW4gZ2l0IHN1YnByb2Nlc3NlcyBpbiBhIHByb2Nlc3MgZ3JvdXA=-->fix: run git subprocesses in a process group<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1623
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
When Forgejo Runner is in host mode and a Docker-based action is invoked, the action cannot interact with the workspace because it's empty. Also, the container's `$PATH` is replaced with the host's `$PATH`. That can lead to the action being unable to invoke basic tools.
This is fixed by bind-mounting the workspace and the `act` directory from the host into the step container. Also, `$PATH` is not longer replaced.
Resolves https://code.forgejo.org/forgejo/runner/issues/1587.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1606): <!--number 1606 --><!--line 0 --><!--description Zml4OiBiaW5kIHdvcmtzcGFjZSBpbnRvIGFjdGlvbnMgY29udGFpbmVyIGluIGhvc3QgbW9kZQ==-->fix: bind workspace into actions container in host mode<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1606
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Forgejo Runner lowercases the attributes `cron` and `timezone` of a `schedule:` trigger before validating them -- and only those. That is inconsistent with workflow validation, that only accepts the lowercase variants. Furthermore, the rest of Forgejo Runner isn't able to handle any other notation than `cron` and `timezone`, anyway. A workflow like
```yaml
on:
schedule:
- CrOn: '* * * * *'
jobs:
test:
runs-on: debian
steps:
- run: |
echo OK
```
would not be accepted by Forgejo today. It only leads to the error "notifier_helper.go:579:handleSchedules() [W] no schedule event".
See also https://code.forgejo.org/forgejo/runner/issues/1319.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1609): <!--number 1609 --><!--line 0 --><!--description Y2hvcmU6IHJlbW92ZSBsb3dlcmNhc2luZyBvZiBjcm9uLCB0aW1lem9uZSBhdHRyaWJ1dGVz-->chore: remove lowercasing of cron, timezone attributes<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1609
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
https://code.forgejo.org/forgejo/runner/pulls/1585 introduced the environment variable `TEST_FEATURES` for switching tests related to particular feature on and off. For example, with `TEST_FEATURES=""`, tests that require Docker would be skipped. Unfortunately, that technique has multiple problems. Environment variables might not be passed on to child processes without it being clearly visible. Also, the usage differs by platform. On top of that, informational messages that are only related to testing were printed by the release binary.
Instead of the environment variable `TEST_FEATURES`, the command line flag `-features` is introduced:
```
$ go test ./... -args -features "docker,lxc"
```
That runs all tests that require the presence of Docker and LXC. It is also the default.
If tests that require Docker should be skipped, run:
```
$ go test ./... -args -features "lxc"
```
To exclude all tests that require the presence of a particular feature, run:
```
$ go test ./... -args -features "-"
```
At the moment, `-features` cannot be controlled when using make targets. That means that `make integration-test` runs all tests that require Docker or LXC.
Supersedes https://code.forgejo.org/forgejo/runner/pulls/1588.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1591): <!--number 1591 --><!--line 0 --><!--description dGVzdDogdXNlIGZsYWdzIGluc3RlYWQgb2YgZW52IHZhcmlhYmxlcyBmb3Igc2tpcHBpbmcgdGVzdHM=-->test: use flags instead of env variables for skipping tests<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1591
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Tests involving Docker are skipped when `runtime.GOOS` is not `linux`. That is unnecessarily rigid and hinders development. There are other operating systems that can run Docker. It makes it impossible to run integration tests on Linux without Docker. Verifying that all tests that require Docker are skipped without Docker being present is impossible on Linux due to that, too.
Instead of relying on `runtime.GOOS`, developers can control whether tests involving Docker should be run with the help of the environment variable `TEST_FEATURES`.
If the variable is undefined, tests involving Docker will be run, because they are enabled by default:
```
$ make integration-test
```
That is the same as:
```
$ TEST_FEATURES="docker" make integration-test
```
If the variable does not contain the string `docker`, tests involving Docker will be **skipped**:
```
$ TEST_FEATURES="" make integration-test
```
If a test requires Docker, use `testutils.RequireTestFeatures(t, testutils.TestFeatureDocker)` to indicate that.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1585): <!--number 1585 --><!--line 0 --><!--description dGVzdDogdXNlIGVudmlyb25tZW50IHZhcmlhYmxlIGZvciBza2lwcGluZyBEb2NrZXIgdGVzdHM=-->test: use environment variable for skipping Docker tests<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1585
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Forgejo Runner does not set the context values `runner.os` and `runner.arch` consistently. When jobs run a [platform supported by GitHub](https://docs.github.com/en/actions/reference/workflows-and-actions/contexts#runner-context), then the values defined by GitHub are used. Unless the host executor is used on 64-bit ARM, because it expects `aarch64` as input, but `runtime.GOARCH` on 64-bit ARM is `arm64`. On platforms not supported by GitHub, executor-specific values are returned, which makes `runner.os` and `runner.arch` unpredictable and therefore useless. As `runner.os` and `runner.arch` are defined by GitHub and therefore have to be compatible with GitHub Actions, the problem is remedied by only returning values defined by GitHub. If Forgejo Runner is executed on other platforms, the literal string "undefined" (without quotes) is returned. If Microsoft expanded the platform reach of GitHub Actions, "undefined" will be replaced.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1583): <!--number 1583 --><!--line 0 --><!--description Zml4OiBzdGFuZGFyZGl6ZSBydW5uZXIub3MgYW5kIHJ1bm5lci5hcmNo-->fix: standardize runner.os and runner.arch<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1583
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
# Per-label container platform specification
Lets a docker runner label declare the OS/architecture passed to the container runtime when pulling and creating images. A single runner on a host that can run several platforms (FreeBSD, macOS) can then serve mixed-platform jobs from one instance, instead of running a separate runner per platform. When the platform is omitted, it keeps being auto-detected, existing configurations are unaffected.
Originating feature request: https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/105
## Usage
String form (CLI --labels, runner.labels list, connection labels):
ubuntu-latest:docker://node:20-bookworm?platform=linux/amd64
freebsd-15:docker://ghcr.io/freebsd/freebsd-runtime:15.0?platform=freebsd/amd64
Mapping form of runner.labels, with image and platform under backend-options:
```
runner:
labels:
freebsd-15:
backend: docker
backend-options:
image: ghcr.io/freebsd/freebsd-runtime:15.0
platform: freebsd/amd64
```
## Design
- Both label forms normalize to a single canonical label string, because runner registration ships labels to the server as strings. The mapping form is sugar over the string form.
- platform is only valid for the docker scheme; platform and image are the only accepted option keys for now, and unknown keys are rejected at startup.
- The platform reaches the container runtime via DefaultPlatform on the job, service, and step containers and the docker-action build. A workflow-level container.options: --platform=... still takes precedence over the per-label default.
This intentionally stays narrow (platform + image) but uses the backend-options shape so it slots into the pluggable-backend work without rework.
## Backwards compatibility
Existing string labels and YAML list labels parse and behave exactly as before; the option query only activates on a literal ?, which never appears in existing image references or LXC arguments.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1571): <!--number 1571 --><!--line 0 --><!--description ZmVhdDogcGVyLWxhYmVsIGNvbnRhaW5lciBwbGF0Zm9ybSBzcGVjaWZpY2F0aW9u-->feat: per-label container platform specification<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1571
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
