You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In many situations you wish to run digger with private runners. For example if you are provisioning resources in a private k8s cluster in this case you will not be able to use cloud runners.
6
+
7
+
While digger does not natively support k8s agents it is very easy to do it indirectly using github actions runners.
8
+
In the typical digger flow you are using a workflow that looks like this:
9
+
10
+
```
11
+
name: Digger Workflow
12
+
on:
13
+
# ....
14
+
jobs:
15
+
digger-job:
16
+
runs-on: ubuntu-latest
17
+
```
18
+
19
+
With github specifically there is good support for [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)
20
+
which means that you can create agents for github actions in your private infrastructure's VPC and github will then run the jobs there.
21
+
22
+
The easiest way to achieve self-hosted runners is by running the agent in something like an EC2 instance. Alternatively if you already have a kubernetes cluster
23
+
you could opt for using the [Actions runner controller](which will provide you with actions right in your cluster). Once you have set up and configured your controllers
24
+
you can then reference the name of your self-hosted runners in the digger workflow:
25
+
26
+
```
27
+
name: Digger Workflow
28
+
on:
29
+
# ....
30
+
jobs:
31
+
digger-job:
32
+
runs-on: my-selfhosted-ubuntu
33
+
```
34
+
35
+
In this way all of digger future jobs will run within your infrastructure.
0 commit comments