Allow disabling service workspace volumes in k8s

[julienvincent]

Currently when using the Kubernetes backend all services are provisioned with the workspace PVC volume mounted. This causes problems when using ReadWriteOnce PVC volumes in multi-node clusters as the service and step Pods can be provisioned onto different nodes.

A workaround for this is to use the PodAffinity controls on the agent:

env:
  WOODPECKER_BACKEND_K8S_POD_AFFINITY: |
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector: {}
          matchLabelKeys: ['woodpecker-ci.org/task-uuid']
          topologyKey: 'kubernetes.io/hostname'

This ensures the step Pods are provisioned onto nodes already containing Pods from the same task. This will always result in co-locating the service Pods with step Pods.

While this kind of works, it means that a single Node now needs to be sized appropriately to host all the service Pods as well as the step Pod which uses them.

A better solution that allows distributing service Pods over all the available nodes is to stop attaching the workspace PVC to service Pods. A similar problem/solution is discussed in #3344, as well as some related discussion in
#5312.

The discussion in #3344 mentions attaching a dedicated PVC to services, but IMO this overly complicates things and adds very little value. I believe that for most use-cases services' won't need to interact with a PVC at all. They are just there to run a database or service dependency.

---

This change introduces two new controls:

• An agent-level environment variable WOODPECKER_BACKEND_K8S_SERVICE_WORKSPACE_VOLUME which defaults to true.
• A step-level Kubernetes backend option backend_options.kubernetes.workspaceVolume which also defaults to true.

If either of these are set to false then the workspace PVC will not be attached to the Pod.

Closes #3344

[woodpecker-bot]

Surge PR preview deployment was removed

[6543]

can we remove the flag, it can just cause issues that are undocumented

[julienvincent]

@6543 Are you referring to the WOODPECKER_BACKEND_K8S_SERVICE_WORKSPACE_VOLUME environment variable?

Happy to remove, but just so I understand - what issues do you foresee this causing? I thought I did update the documentation for this config.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 41.73%. Comparing base (8363eff) to head (53b0965).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6644      +/-   ##
==========================================
+ Coverage   41.60%   41.73%   +0.12%     
==========================================
  Files         432      433       +1     
  Lines       28805    28900      +95     
==========================================
+ Hits        11983    12060      +77     
- Misses      15747    15754       +7     
- Partials     1075     1086      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[6543]

as it is a backemd flag, it is an agent flag.

let agent config change pieline execution config that is transparent to the server and git-commited config but can affect workflow to fail is something i dont want to encourage :)

[julienvincent]

@6543 Makes sense. I've removed the flag