Drone build restart does not pass parameters

Drone Support
1

We recently upgraded our docker-runners and noticed behavior we’d like some clarification on.

Previously we were able to restart a build and pass a specific parameter/env var but now it seems to keep the one in .drone.yml if it is in the pipeline.

So if we have:

kind: pipeline
type: docker
name: Test a Thing

platform:
os: linux
arch: amd64

trigger:
branch:
exclude:
- master
event:
- push

steps:

  • name: test-env
    image: alpine:latest
    commands:
    • env | grep TEST
    • echo $TEST

Now we run a build, TEST is blank, like we expect. If we then restart it with this command:

drone build restart githubrepo/test 02 --param=TEST=“parameter env passed by drone build restart”

Then our output is “parameter env passed by drone build restart” which we expect. So far so good.

But if in our pipeline we add to the test-env step something like:

environment:
TEST: “pipeline step env”

then the output will ALWAYS be “pipeline step env” - even when we run the same build command (such as drone build restart githubrepo/test 04 --param=TEST=“parameter env passed by drone build restart”) – this wasn’t the case before. What could be the cause of this?

2

@sethagari I took a look and it seems a restart never included the custom parameters, so I went ahead and patched accordingly [1]. This change should be available in drone/drone:latest within the next 15 minutes. Hope that helps!

[1] https://github.com/drone/drone/commit/2006bac45c731a41c6ffba7ff9139b6bee2a6cfc

3

This is great. Thank you!

4

actually, I think I may have read too fast. I did fix an issue (that when you restart, it loses any customer parameters from the restarted build). However, it sounds like the issue you are describing is slightly different. It sounds like when you declare the environment variable in the yaml, the value in the yaml takes precedence over any custom parameters that were provided? This is something I will need to look into further.

5

Thanks for the quick response. I think our engineers have a work-around for now, but I’ll be watching releases to see if this issue can be resolved. If not, understandable.