Report status for detached steps and services

[6543]

---

close #6033
resolve #2831

[codecov]

Codecov Report

❌ Patch coverage is 0% with 64 lines in your changes missing coverage. Please review.
✅ Project coverage is 31.66%. Comparing base (fe9db66) to head (48d2ee4).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
pipeline/pipeline.go	0.00%	35 Missing ⚠️
pipeline/backend/docker/docker.go	0.00%	25 Missing ⚠️
pipeline/backend/local/local.go	0.00%	3 Missing ⚠️
pipeline/backend/dummy/dummy.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6039      +/-   ##
==========================================
- Coverage   31.71%   31.66%   -0.05%     
==========================================
  Files         420      420              
  Lines       28378    28413      +35     
==========================================
- Hits         8999     8996       -3     
- Misses      18559    18596      +37     
- Partials      820      821       +1     

☔ 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]

TODO: restructure pipeline/*.go to use submodules

• pipeline/error.go -> pipeline/errors/...
• pipeline/pipeline.go#Runtime -> pipeline/runtime/runtime.go
• pipeline/pipeline.go#execAll -> pipeline/runtime/executor.go
• pipeline/shutdown.go -> pipeline/runtime/shutdown.go
• pipeline/logger.go ->pipeline/logging
• pipeline/tracer.go -> pipeline/tracing
• X -> state/state.go?
• ...

[anbraten]

I would argue detached steps and services should let a pipeline fail. For example if you are testing a database / woodpecker server in some kind of integration test if they crash or fail the pipeline should be marked as failed as well. Users could still use "/bin/mytool || exit 0" if there service is likely to fail and should be ignored

[6543]

in this regards there is also the option to ignore errors...

[6543]

I'll test to see what a common case will do right now (mariadb & postgress as db)

[6543]

well needs more work on that front ...

[6543]

Now

expl. failing services and detached

## normal have them succeed

[6543]

5:42PM ERR agent/rpc/client_grpc.go:181 > grpc error: wait(): code: Unknown error="rpc error: code = Unknown desc = workflow finished with error "                                                 
5:42PM ERR agent/runner.go:112 > server returned unexpected err while waiting for workflow to finish run error="rpc error: code = Unknown desc = workflow finished with error " pipeline=129 repo=test/test-bash-ci workflow_id=129  

fixed by 4e5d5db

[6543]

the approach how it's done is not the simplest code ... but I would like to move refactoring that stuff in a new pull after #6073 got merged witch is based on this pull :)

[qwerty287]

Seems fine as well, but also untested.