Draft: Implement variables for pipeline workflow rules
What does this MR do?
This is just a draft. Just testing if the way is good or not. No need to review refactorings for now.
Related to #294232 (closed)
This MR implements the variables
keyword for rules
of pipeline workflow. This is only for workflow:rules, the previous MR implemented for job:rules
.
- Added
yaml_variables
attr_accessor
inCi::Pipeline
to store variables defined in YAML. - Added logic in
lib/gitlab/ci/pipeline/chain/evaluate_workflow_rules.rb
that applying rules for workflow by changing theyaml_variables
ofCi::Pipeline
. - We have logic in
lib/gitlab/ci/config/entry/processable.rb
that merging root variables with job variables. I've added thesource
attribute to this logic in order to determine where variables come from. - Then, added logic in
lib/gitlab/ci/pipeline/seed/build.rb
to override only variables with the sourceworkflow
.
Why did I choose this way?
- Our
inherit
logic is inlib/gitlab/ci/config/entry/processable.rb
, so it looks like that we need to apply "inheriting" variables in here. - However, we have the result of
rules
in the "create pipeline" logic and we need that result to override workflow variables. - We need to use the variables from the result of
rules
to override the job variables from the workflow.
TODO: Add a feature flag
Screenshots (strongly suggested)
variables:
VAR1: my var 1
VAR2: my var 2
workflow:
rules:
- if: $CI_COMMIT_REF_NAME =~ /master/
variables:
VAR1: overridden var 1
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
VAR2: overridden var 2
VAR3: new var 3
- when: on_success
If the first condition is satisfied, then the total variables will be:
- VAR1: overridden var 1
- VAR2: my var 2
If the second condition is satisfied, then the total variables will be:
- VAR1: my var 1
- VAR2: overridden var 2
- VAR3: new var 3
If no condition is satisfied, then the total variables will be:
- VAR1: my var 1
- VAR2: my var 2
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Edited by Furkan Ayhan