tree 2a86828bcbce13aa1f9b268c100d649306b33c4c
parent 8d81642e40b8e5b074ca6ad5ecece74e2f319c62
author Carmelo Cascone <carmelo@opennetworking.org> 1585016944 -0700
committer Carmelo Cascone <carmelo@opennetworking.org> 1585069781 -0700

Skip service upgrade test if the xos-core version requirements don't match

This is a first attempt at making the service upgrade job aware of the
xos-core version, and to allow merging service patches that require
xos-core 4.0.0.

The current implementation verifies that the `core_version` string found
in the released service's config.yaml is the same found in the patchset
to verify. If not, return SUCCESS immediately.

For example, given a released and patchset config.yaml's core_version
property:
- if RELEASED == ">=3.2.0" && PATCHSET == ">=3.2.0" -> RUN
- if RELEASED == ">=3.2.0" && PATCHSET == ">=4.0.0" -> SKIP (success)
- if RELEASED == ">=3.2.0" && PATCHSET == "=3.2.0"  -> SKIP (success)
- if RELEASED == ">=3.2.0" && PATCHSET == ">=3.2"   -> SKIP (success)
- if RELEASED == ">=3.2.0" && PATCHSET == "foobar"  -> SKIP (success)

A smarter implementation could parse the string and use semver logic to
decide (1) whether it exists a version of xos-core that satisfies both
the released and patchset requirement, (2) deploy that version of
xos-core, and (3) run the pipeline. However, such and implementation
smells of canned worms, so we keep things simple for now...

Change-Id: I2cc1be579398c84d4e8c44c333be20e012884e20