|
Why the shift to environment variables over parameters? I am interested in the motivation so that we can see if there is a way to meet that need and avoid the following issues:
This makes it much harder to create a Jenkins job which can be triggered by GitLab or by manual execution.
Before, you simply defined the job with appropriate parameters, then filled them out in the case of a manual execution.
Now you need to define parameters, then write a groovy script to conditionally overwrite environment variables. If you want to use defaults, this is even harder:
1. Define parameters without defaults.
2. Write groovy script to write environment vars using the following order or precedence: Parameter if not empty; else environment if not empty; else default
This creates a tedious setup which is difficult to maintain across several projects.
Such an implementation also hides defaults from the end user when they start the build. The only viable work-around to that is to write the defaults into the helper-text for each parameter. This means that if your defaults change, you must update the groovy script and the documentation further adding to the maintenance cost.
This change makes it is much harder to now determine what the execution parameters of a specific build were.
Before, you could just inspect the build parameters. The values which are relevant to the build operations are clearly visible.
Now, you must sift through the very cluttered list of environment variables. Even if a gitlab-value is irrelevant for the build operations it shows up in the list further obfuscating what was used as build parameters.
|
