Configurable container prefix #78
Labels
No Label
kind
bug
kind
build
kind/compatible
kind
dependencies
kind
docs
kind
enhancement
kind
feature
kind
help wanted
kind
proposal
kind
refactor
related
act
related
environment
related
exec
related
gitea
related
workflow
reviewed
confirmed
reviewed
duplicate
reviewed
invalid
reviewed
needs feedback
reviewed
wontfix
reviewed
workaround
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/act_runner#78
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I'd like to run several org runners on a single, shared VM to conserve resources. They use different host users, systemd units, and settings.
Would it be possible to make ContainerNamePrefix configurable via environment so that there would be no chance of different runner jobs conflicting?
Thanks in advance for considering.
Every task has their own container, the name contains a task id. So I think they should not be conflicted if they are on the same Gitea instance.
I'm sharing between two Gitea instances (on the same LAN). One has two runners bound to two different orgs, another one has a global runner.
I think a collision is possible because
Sprintf("GITEA-ACTIONS-TASK-%s", eventName)
is not enough to guarantee container name uniqueness.p.s. I understand that this is not best practice in any way whatsoever but it's not practical to make a separate VM for every runner which are mostly idle, too much wasted RAM on the hypervisor.
In the end here's what I did as a temporary workaround (this envvar pair is saved to runner/.env by an ansible role which deploys runner instance), hoping for a proper fix tho.
Try to use dind(docker in docker) to isolate different runner environments
No, rewriting all pipelines to use docker-on-docker is not a valid workaround here.
It's also an objectively bad practice but that's beside the point.