So the ordering of the environment variables doesn't actually matter in practice - we end up resolving the environment variables later using hudson.EnvVars.overrideExpandingAll(Map), which does some nifty magic behind the scenes to figure out the right order to resolve the variables in based on their contents. Is nifty indeed.

This is something we can think about doing when we revisit the environment variable control however the use case isn't particularly strong IMO.

bitwiseman don't bother assigning these to me - I see everything anyway and its just one more step during triaging to unassign myself

jamesdumay I don't think I was assigning them intentionally. I'll double check.

abayer
On Declarative 1.1.1, with this Pipeline, I get an error:
repo: https://github.com/bitwiseman/hermann/
branch: issue/blue-ocean-editor/env-order

pipeline {
  agent any
  environment {
    test = "${test2 + test3}"
    test2 = "value2"
    test3 = "${test2}"
  }
  stages {
    stage('Install') {
      steps {
        sh 'echo "${test}"'
      }
    }
  }
}

"groovy.lang.MissingPropertyException: No such property: test2 for class: groovy.lang.Binding"

Huh. Interesting. Not 100% sure that'd work if it was in the expected order...it'll definitely resolve any "${foo}" references correctly, but the env var resolution doesn't grok "${test2 + test3}" as env vars, so it doesn't know what to do about them. Open a JIRA for that?