Closed smainz closed 1 year ago
Any hint where to start to fix this? metadata.go copies the value, but maybe before the status is set to success / failure.
It's in the drone compatibilety file ...
I guess it's a regression of some refactor
-> https://github.com/woodpecker-ci/woodpecker/pull/1284 would likely fix it ... to, ...
uh now ... that one is set by the agent again
agent/runner.go 293: state.Pipeline.Step.Environment["CI_PIPELINE_STATUS"] = "success" 312: state.Pipeline.Step.Environment["CI_PIPELINE_STATUS"] = "failure"
Do you want me to start fixing it?
sure if you d'like to, go on :)
Hope it is not beyond my current skill level, but shouldn't it be enough to move the call to the drone_compatibility before each call to Runner.run() where the step status is updated? No need to have these env vars in the metadata (is it is only for compatibility with drone plugins).
just copy the env vars before the
return nil
Component
server, agent
Describe the bug
While trying to port some pipelines from drone to woodpecker-ci I found out, that the drillster/drone-email plugin is not working with woodpecker-ci.
Even if the build is successful, the plugin will always send failure notifications. The reason is, that the plugin checks for
DRONE_BUILD_STATUS=='success'
(DRONE_BUILD_STATUS
is put into the context of a template asbuild.status
, the templates uses this to create the message / subject).The reason seems is that
DRONE_BUILD_STATUS
has the valuepending
. In the docs it says:DRONE_*
environment variables are not mentioned.A simple
env | sort
reveals:Is it intended behavior that
CI_BUILD_STATUS
differs fromDRONE_BUILD_STATUS
or a bug?If the DRONE_* environment variables are just a deprecated legacy, i can offer to fork the plugin and use the correct environment variable. For this it would be helpful, if someone explained to me the difference between
BUILD_STATUS
,JOB_STATUS
,PIPELINE_STATUS
andSTEP_STATUS
and when they are set.System Info
Additional context
No response
Validations