diff options
author | ottero <rodrigo.ottero@est.tech> | 2019-05-28 17:16:19 +0000 |
---|---|---|
committer | Gerrit Code Review <gerrit@onap.org> | 2019-05-28 17:16:19 +0000 |
commit | 88dd1cbd853a100aac64f176a1520db5b6c3d9a0 (patch) | |
tree | 5e75d17de010d279ce4e94e232adfe4442174085 /docs/submodules/ccsdk | |
parent | 0473b479e187e903870fdbbe5d5fb686c7d970df (diff) |
Update git submodules
* Update docs/submodules/ccsdk/cds.git from branch 'master'
to 5e1e26053d13c9e693762c69b43eff3093c34d29
- Returning null for unresolved variables
When Blueprints Processor was not able to evaluate a variable, it would
set its value to null.
The expected behaviour would be to set the value to the default repres-
entation in the formal notation as defined by Apache Velocity, which is
a dollar followed by the name of the variable between curly braces. For
example, if the value of the variable pnf-id could not be evaluated in
runtime, its value would be defined as the string "${pnf-id}".
The problem happened during evaluation of the variables that would be
later sent to the template-meshing code for processing.
The fix was to add a check before the value was assigned to the varia-
ble; if the was not null, the assignment will happen normally. Otherwi-
se, if the evaluation resolves to null, the variable receives the defa-
ult value (string "${<variable name>}").
Besides the tests that were put in place to test the code changed for
this fix, two tests were added to the existing test case of the templa-
te meshing code, to act as regression test.
Change-Id: I635afb1eba4c0d45b821811f0119fa6c87ea9542
Issue-ID: CCSDK-1358
Signed-off-by: ottero <rodrigo.ottero@est.tech>
Diffstat (limited to 'docs/submodules/ccsdk')
m--------- | docs/submodules/ccsdk/cds.git | 0 |
1 files changed, 0 insertions, 0 deletions
diff --git a/docs/submodules/ccsdk/cds.git b/docs/submodules/ccsdk/cds.git -Subproject 1f69e1c3569196305c23f085cfbc03bdba14f4e +Subproject 5e1e26053d13c9e693762c69b43eff3093c34d2 |