| Summary: | Missing manifest properties should be noted as warnings | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Maciej Bendkowski <maciej.bendkowski> |
| Component: | Deployment | Assignee: | Maciej Bendkowski <maciej.bendkowski> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne |
| Version: | 6.0 | ||
| Target Milestone: | 8.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Maciej Bendkowski
In fact maybe it shouldn't even be a warning, since the deploy wizard will prompt the user for any missing values, or they may be using a command line or deployment script that fills in the missing values. From the context of the manifest editor it is hard to conclude that a missing value is a problem. (In reply to John Arthorne from comment #1) > In fact maybe it shouldn't even be a warning, since the deploy wizard will > prompt the user for any missing values, or they may be using a command line > or deployment script that fills in the missing values. From the context of > the manifest editor it is hard to conclude that a missing value is a problem. If warnings are basically equivalent to "We found potential problems with your manifest" I'd still want them to be visible in the manifest editor. To get the warnings while writing a manifest is essentially having a running background lint. We could make this behavior configurable via settings at some point in the future. I've disabled the missing "command" property warning. It should be noted, that there's only one remaining issue of this type, i.e. the missing "name" property. We should not provide a generic all-for-one solution to warnings and missing properties. Instead, we should re-use what we already have, i.e. deployment planners exposed via REST API. Dedicated editor plugins can consume this API and produce meaningful warnings and/or manifest errors based on the application type and other resources. Marking as closed. |