Open casdr opened 8 months ago
@casdr I am not sure I fully understand the description. The code snippets you provided (export variable=value) override the environment variable value inside the container with user-defined values. Also note that CI_ variables were deprecated many years ago and should not be used.
In terms of the DRONE_BUILD_STATUS variables not being set correctly by Drone, I created this sample yaml which you can use to test out the behavior:
kind: pipeline
type: docker
name: default
steps:
- name: a
image: alpine:3
commands:
- echo $DRONE_BUILD_STATUS
- name: b
image: alpine:3
commands:
- echo $DRONE_BUILD_STATUS
- exit 1
- name: c
image: alpine:3
commands:
- echo $DRONE_BUILD_STATUS
when:
status: failure
You will note that Drone prints the correct status in each example. The second step returns a non-zero exit code which results in the third step printing a failure status.
[a:1] + echo $DRONE_BUILD_STATUS
[a:2] success
[b:3] + echo $DRONE_BUILD_STATUS
[b:4] success
[b:5] + exit 1
[c:6] + echo $DRONE_BUILD_STATUS
[c:7] failure
@bradrydzewski Sorry for the confusing description. The snippets I posted are the result of running the export
command in a step, so this doesn't override the environment but shows the current state.
The CI_
variables are showing the same result as the DRONE_
variables. I've copied your exact config into my .drone.yml
and changed the type to kubernetes, but I'm still getting different results:
[a:1] + echo $DRONE_BUILD_STATUS
[a:2] success
[b:3] + echo $DRONE_BUILD_STATUS
[b:4] success
[b:5] + exit 1
[c:6] + echo $DRONE_BUILD_STATUS
[c:7] success
This makes me think the issue lies within the Kubernetes pipeline provider.
I'm running Drone v2.20.0
Keep in mind that you cannot export a variable from one step to another. If you want to share state between steps you need to do so using disk. here is an example:
kind: pipeline
type: docker
name: default
steps:
- name: a
image: alpine:3
commands:
- echo FOO=bar >> .env
- name: b
image: alpine:3
commands:
- source .env
- echo $FOO
which returns the following:
[a:1] + echo FOO=bar >> .env
[b:2] + source .env
[b:3] + echo $FOO
[b:4] bar
In terms of docker vs kubernetes, keep in mind that the Kubernetes runner is experimental and not recommended for production use at this time. We strongly recommend the docker runner which is battle tested and can use the official helm chart.
I'm not using the export command to override or set a variable, only for displaying the current variables, like this:
kind: pipeline
type: kubernetes
name: default
steps:
- name: a
image: alpine:3
commands:
- exit 1
- name: b
image: alpine:3
commands:
- export
I wasn't aware that the kubernetes runner is experimental, we've been running like this for a few years now. I'll see if I can look into the issue myself in the meantime.
This seems to be related to kubernetes-runner. When I execute the .drone.yaml
script provided by @bradrydzewski using my local docker daemon (with type: docker
), I get the expected output:
[a:1] + echo $DRONE_BUILD_STATUS
[a:2] success
[b:3] + echo $DRONE_BUILD_STATUS
[b:4] success
[b:5] + exit 1
[c:6] + echo $DRONE_BUILD_STATUS
[c:7] failure
However, when I execute the same script using kubernetes-runner (with type: kubernetes
), it doesn't work as expected:
[a:1] + echo $DRONE_BUILD_STATUS
[a:2] success
[b:3] + echo $DRONE_BUILD_STATUS
[b:4] success
[b:5] + exit 1
[c:6] + echo $DRONE_BUILD_STATUS
[c:7] success
As a workaround, I create two steps, one with
when:
status:
- success
another one with
when:
status:
- failure
for the time being.
Is kubernetes runner still maintained? I cannot see Issues page in the drone-runner-kube
project. Can I hope that this will be resolved anytime soon? I am open to any other workarounds and solutions.
This is a followup on issue https://github.com/drone-plugins/drone-slack/issues/162#issuecomment-1788143538.
I noticed that (at least) the
DRONE_BUILD_
environment variables aren't updated across steps in the same stage.For example, when having a step after a failed build, I'm getting the following result:
I think this behaviour is incorrect, but it might be a design choice.