feat(artifacts): add support for artifacts key

[timhuynh94]

Overview

This branch wires the worker into the new artifacts + object storage pipeline by:

• Adding storage configuration and clients to the worker process.
• Extending the executor (linux/local) engines to accept a storage engine and handle the artifacts key.
• Adding runtime logic (Docker) to collect artifacts files from containers and hand them off to storage / the server.
• Touching step skip logic, middleware, and tests so test reports integrate cleanly into existing execution flow.
• Depends on feat(artifacts): Object storage integration and artifacts key server#1385
• Depends on feat(storage): storage getSTSCreds sdk-go#380

---

Architecture

1. Worker config + storage hookup

• cmd/vela-worker/flags.go, run.go, worker.go
  • CLI now includes storage flags (driver, endpoint, access/secret key, bucket) and passes them into storage.Setup.
  • Worker gains fields for Storage *storage.Setup (config) and Storage storage.Storage (runtime client).
• cmd/vela-worker/operate.go
  • On startup, the worker calls VelaClient.Storage.GetInfo() to fetch storage configuration from the server.
  • If storage is enabled, it:
    • Fills in any missing worker config (endpoint, bucket, access/secret).
    • Builds a storage client via storage.New(...).
    • Stores the client on w.Storage and logs driver/bucket/endpoint.
  • If storage is disabled, it explicitly clears storage config and sets w.Storage = nil.

2. Executor setup (linux/local)

• executor.Setup now includes a Storage storage.Storage field.
• cmd/vela-worker/exec.go
  • If w.Storage was successfully initialized, it is passed into the executor setup.
  • The executor is created from a populated executor.Setup struct instead of an inline literal.
• executor/executor_test.go
  • Tests construct enabled/disabled storage setups and ensure:
    • Linux and local executors can be created with storage.
    • The top‑level executor respects the Storage field in executor.Setup.

3. Linux / local executor behavior for artifacts

• executor/linux/{build.go,stage.go,outputs.go,report.go,artifacts.go}
• executor/local/{build.go,stage.go} and related tests

These pieces:

• Thread the storage engine into the linux/local executor implementations.
• When a pipeline step is configured with the artifacts key, they:
  • Collect artifacts file paths from the runtime.
  • Use the storage client (when enabled) to move those files into the configured bucket.
  • Prepare the metadata so the server (via the Vela SDK) can associate uploads with artifacts records.

4. Runtime integration

• runtime/docker/artifacts.go (+ artifacts_test.go)
  • Adds Docker‑specific helpers for:
    • Discovering artifacts files in a container given paths from the pipeline definition.
    • Pulling those files out so the executor can upload them to storage / report them to the server.
• runtime/engine.go
  • Wires the new test report helper into the runtime lifecycle so it runs at the appropriate point in a build.
• runtime/kubernetes/container.go
  • Introduces PollFileNames as a no‑op for Kubernetes: artifacts file polling is not supported for dynamic pod environments yet.

5. Step skipping, middleware, and wiring

• internal/step/skip.go (+ tests)
  • Updated to account for new behavior around test‑related steps and storage, so pipelines behave sensibly when storage is disabled or unavailable.
• router/middleware/executor/executor_test.go
  • Ensures the executor wiring path continues to work with the new Storage field in executor.Setup.

6. Dependencies

• go.mod, go.sum
  • Bump / align dependencies (including sdk-go, server storage packages, and Docker) to versions that include the new artifacts and storage APIs.