As a developer, you need to leverage Redis in your workflow. What is the best way to use Redis on a self-hosted Linux runner without affecting future workflow runs?

Question

Options

• AInstall Redis on the hosted runner image and place it in a runner group. Specify label: in your job
• BSet up Redis on a separate machine and reference that instance from your job.
• CSpecify container: and services: in your job definition to leverage a Redis service container.
• DAdd a run step to your workflow, which dynamically installs and configures Redis as part of your

• A
  5% (2)
• B
  8% (3)
• C
  70% (28)
• D
  18% (7)

Explanation

Service containers defined with the services: key in a job spin up Docker containers alongside the job, provide the required service (Redis in this case), and are automatically torn down when the job finishes. This is the cleanest approach because it is ephemeral-each run gets a fresh Redis instance with no state leakage into future runs. Installing Redis directly on the runner image (A) persists state and affects all future runs. Using a separate machine (B) adds infrastructure complexity. Dynamically installing Redis in a run step (D) works but is slower and still risks leaving state on the runner.

No community discussion yet for this question.