Top-level vs stage-level environment for DEPLOY_TARGET consistency in steps and post
0 reputation · 27 Aug 2024, 20:10 UTC
A declarative pipeline needs a single value for DEPLOY_TARGET that is used in stage steps, failure handling, and archiving. The documented approaches are a top-level environment block that provides a pipeline-wide default and a stage-level environment block that is scoped to that stage.
The concrete constraint is consistent resolution of the same key across steps and the stage post block. Declarative Pipeline environment scoping is implemented by Pipeline plugins rather than Jenkins core alone, so precedence and visibility can be version sensitive.
The unresolved behavior concerns precedence and timing for post actions. It is unclear whether a stage post block observes the stage-level override, falls back to the top-level value, or uses a value captured earlier in the stage execution. This matters when cleanup, notifications, or artifact handling depend on DEPLOY_TARGET.
Does a stage post block resolve environment variables from the stage scope or from the pipeline scope? Is the precedence of a stage-level entry over a top-level entry stable across Declarative Pipeline plugin versions? Should DEPLOY_TARGET be defined explicitly at stage level to guarantee consistent use in steps and post actions?