Update VIP-specific descriptor checks #47
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add author field - Add missing '@' character in appname - Cross-reference comment to similar rules in VIP-portal
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a sibling PR to virtual-imaging-platform/VIP-portal#577, which harmonizes the VIP-specific checks done on top of
bosh validate, when importing a descriptor in either VIP-portal web UI or withvipapps.pycommand-line.The lack of a check on the
authorfield invipapps.pycaused theCoil_Characterization-3.3.jsondescriptor to be imported without such a field during the migration last week, which would have been rejected if UI import had been used : this has been fixed in virtual-imaging-platform/vip-apps-boutiques-descriptors@2a590fe, this descriptor should be re-imported for consistency.A remaining difference between these two implementations is that VIP-portal does some checks on the
vip:dotcustom property, whilevipapps.pydoesn't. These checks are rather incomplete anyway compared to the custom properties that are actually implemented, so some upcoming decision remains on :vipapps.py: in theory this could be done by either having VIP-portal expose a descriptor validation API thatvipapps.pywould call (single Java implementation in VIP-portal), or by having a command-line descriptor check implemented in VIP-python-client that VIP-portal would call in addition tobosh validate(single Python implementation in VIP-python-client, packaging TBD)