You are here: start » en » Internal Documentation » DokuWiki extensions (WvdS) » Pipelines » Quickstart: run the first pipeline and read its log

Quickstart: run the first pipeline and read its log

The shortest way from “the plugin is installed” to “a run is recorded, attributed to you, and its three log streams are readable”. Three steps, about ten minutes.

Prerequisites

  • wkdopipelines, wkdocore, wkdostorage and wkcore are installed and enabled.
  • A project, and a pipeline defined in it. If there is none, the screen says so: No pipelines defined for this project yet.
  • Permission to run, which is not the same as permission to view — see step 1.
  • The server can execute whatever the pipeline invokes, as the web server's user.

Step 1: check which permission you hold

Two different questions govern this plugin:

Action Asks about
Viewing runs and logs your project role
Starting a run the wider permission context

Being able to see a pipeline does not imply being able to start it. That asymmetry is deliberate: reading a history is ordinary project membership, starting a process on the server is not.

Step 2: run it

Open the project's Pipelines hub:

/doku.php?id=en:projects:acme:pipelines&do=wkdopipelines

Pick a pipeline from the list and start it.

Step 3: read the log

Open the run. The log is captured in three separate streams:

Stream Contains
out What the process wrote to standard output.
err What the process wrote to standard error.
sys What the runner itself did — its own account of the attempt.

The third is the one nobody expects and the one that answers the first question after a failure.

Check the result

  • The run is in the list with Status (queued, running, succeeded, failed, canceled), Started, Finished, Exit and Triggered by — and that last one carries your name.
  • All three streams are readable separately.
  • The run history holds earlier runs with their actors and outcomes. “It worked yesterday” becomes checkable rather than remembered.

This is how sys separates the two failures that otherwise look identical — the process failed, or the runner never started it:

  • Content in out/err and a failure → the process ran and failed.
  • Nothing in out/err, something in sys → it never started, and sys says why.

A merged log makes exactly that distinction the hardest to recover. Separate streams make it the first thing you see.

Next step

  • wkdodashboard — the project's pipelines on its front page.
  • wkdopipelines (German) — the package page: the execution policy, the runner and the logger.
en/wiki/dwe/wkdopipelines/quickstart.txt · Last modified: by 0.0.0.0