A daemon that connects to a Forgejo instance and runs jobs for continuous integration. The installation and usage instructions are part of the Forgejo documentation
https://forgejo.org/docs/latest/admin/actions/
- Go 86.4%
- JavaScript 11.7%
- Shell 1.4%
- Makefile 0.3%
Eugene F.
2db8d5e98d
All checks were successful
cascade / debug (push) Has been skipped
checks / validate mocks (push) Successful in 38s
checks / Build Forgejo Runner (push) Successful in 48s
checks / validate pre-commit-hooks file (push) Successful in 41s
checks / Build unsupported platforms (push) Successful in 44s
example / docker-build-push-action-in-lxc (push) Successful in 1m43s
checks / runner exec tests (push) Successful in 34s
/ example-docker-compose (push) Successful in 2m43s
/ example-on-demand (push) Successful in 4m36s
/ example-lxc-systemd (push) Successful in 8m7s
checks / integration tests (docker-latest) (push) Successful in 12m40s
checks / integration tests (docker-stable) (push) Successful in 15m16s
cascade / forgejo (push) Successful in 45m10s
When using `uses: docker://...` in workflows, step containers are created with `NetworkMode: "container:<job_container_name>"`, which makes them share the entire network namespace with the job container, including:
- Network interfaces
- IP addresses
- Hostname
- Ports and localhost
## Reproduction:
```yaml
jobs:
test:
runs-on: ubuntu-latest
container: alpine:latest
steps:
- run: hostname
- uses: docker://busybox:latest
with:
args: hostname
```
When you exec into the step container, `hostname` returns the job container's ID, not its own. This makes debugging confusing and breaks the expected isolation model.
## Expected Behavior
As a user, when I specify `uses: docker://image`, I expect:
1. Container isolation: The step runs in a separate, isolated container
2. Own identity: The container has its own hostname (container ID by default)
3. Network communication: Can still communicate with job container and services via Docker network
## Solution
Changed network configuration in `step_docker.go` to connect step containers via network name instead of namespace sharing:
## Maybe Breaking Changes
This *may* change behavior for workflows that rely on shared network namespace:
### Potentially affected pattern:
```yaml
jobs:
test:
container: node:18
steps:
# If something in job container listens on localhost:8080
- run: node server.js &
# This docker:// step tries to access it
- uses: docker://curlimages/curl:latest
run: curl http://localhost:8080 # Will fail after this PR
```
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](#1333): <!--number 1333 --><!--line 0 --><!--description Zml4OiBJc29sYXRlIHN0ZXAgY29udGFpbmVycyBuZXR3b3JrIG5hbWVzcGFjZSB0byBtYXRjaCBkb2NrZXI6Ly8gYWN0aW9uIHNlbWFudGljcw==-->fix: Isolate step containers network namespace to match docker:// action semantics<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: #1333
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Co-authored-by: Eugene F. <grand@codabra.io>
Co-committed-by: Eugene F. <grand@codabra.io>
|
||
|---|---|---|
| .forgejo | ||
| act | ||
| contrib | ||
| examples | ||
| internal | ||
| release-notes | ||
| testutils | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| .pre-commit-hooks.yaml | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| Makefile | ||
| README.md | ||
| RELEASE-NOTES.md | ||
| renovate.json | ||
Forgejo Runner
A daemon that connects to a Forgejo instance and runs jobs for continuous integration. The installation and usage instructions are part of the Forgejo documentation.
Reporting security-related issues
Sensitive security-related issues should be reported to security@forgejo.org using encryption.
License
The Forgejo runner is distributed under the terms of the GPL version 3.0 or any later version.
Architectures & OS
The Forgejo runner is supported and tested on amd64 and arm64 (binaries and containers) on Operating Systems based on the Linux kernel.
Work may be in progress for other architectures and you can browse the corresponding issues to figure out how they make progress. If you are interested in helping them move forward, open an issue. The most challenging part is to setup and maintain a native runner long term. Once it is supported by Forgejo, the runner is expected to be available 24/7 which can be challenging. Otherwise debugging any architecture specific problem won't be possible.
Hacking
The Forgejo runner is a dependency of the setup-forgejo action. See the full dependency graph for a global view.
Building
- Install Go and
make(1) make build
Linting
make lint-checkmake lint# will fix some lint errors
Testing
The workflow that runs in the CI uses similar commands.
Without a Forgejo instance
- Install Docker
make test integration-test
The TestRunner_RunEvent test suite contains most integration tests
with real-world workflows and is time-consuming to run. During
development, it is helpful to run a specific test through a targeted
command such as this:
go test -count=1 -run='TestRunner_RunEvent$/local-action-dockerfile$' ./act/runner
With a Forgejo instance
- Run a Forgejo instance locally (for instance at http://0.0.0.0:8080) and create as shared secret
export FORGEJO_RUNNER_SECRET='AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
export FORGEJO_URL=http://0.0.0.0:8080
forgejo forgejo-cli actions register --labels docker --name therunner --secret $FORGEJO_RUNNER_SECRET
make test integration-test# which will run addional tests because FORGEJO_URL is set
end-to-end
- Follow the instructions from the end-to-end tests to run actions tests locally.
./end-to-end.sh actions_teardown# stop the Forgejo and runner daemons running in the end-to-end environment( cd ~/clone-of-the-runner-repo ; make build ; cp forgejo-runner /tmp/forgejo-end-to-end/forgejo-runner )# install the runner built from sources./end-to-end.sh actions_setup 13.0# start Forgejo v13.0 and the runner daemon in the end-to-end environment./end-to-end.sh actions_verify_example echo# run the echo workflowxdg-open http://127.0.0.1:3000/root/example-echo/actions/runs/1# see the logs workflowless /tmp/forgejo-end-to-end/forgejo-runner.log# analyze the runner logsless /tmp/forgejo-end-to-end/forgejo-work-path/log/forgejo.log# analyze the Forgejo logs