Starlark conversion cache key does not include build parameters


I’m having a serious issue with our starlark conversion since our drone instance got updated to 1.9.x.

"environment": {
"commands": {

Shows me that DRONE_SOME_VALUE and SOME_VALUE mismatch because the result of"DRONE_SOME_VALUE", "SOME_DEFAULT") seems to be from some old build.
FWIW I’m doing promotion builds, maybe the values are inherited from some older build in some way? What’s very strange about this is, that DRONE_SOME_VALUE has the correct up to date value, SOME_VALUE has an outdated value from a previous build.
I’m wondering if this might be a value of some older/the initial build of some revision?

As only the value of is outdated, I’m wondering if maybe the result of the conversion is cached or something like that.

Obviously the example I’m giving can be easily worked around, but there are other places in our code that break when the context is not up to date :-/

I’ve now switched to regular builds instead of promotion builds and I’m seeing the very same issue.

By now I’m pretty confident that I can only set parameters for the first build of a certain commit - no matter if it’s a regular build or a promotion build, for new builds of the same commit the parameters of the very first build are reused.

Testing has been done with drone-cli and my PR:

Interestingly I have a check

def main(ctx):
    if"DRONE_START_BUILD", "false") == "true":
        return interesting_pipelines()
        return lame_push_pipelines()

Which works on push (running the “lame pipelines”) and runs the other pipelines on the first drone-cli triggered build. Retriggering manually without parameters leads to the context of the very first manual (non-push) build being reused.
Maybe the cache is independent somehow? One built is shown in the webui as dschmidt pushed HASH to BRANCH" and the manual build is displayed as dschmidt pushed HASH`.

I’m pretty sure this commit broke it (at least from reading the code, I can’t easily revert and test).

As you can see parameters do not invalidate the cache, it perfectly matches the symptoms I’m seeing.

we will look into resolving the caching key issue, in the meantime, we recommend using version 1.9.0 which has caching disabled by default.

1 Like