Added all events slated for Drop 1 and updated README with links. #3
Conversation
Added descriptions of EiffelActivityFinishedEvent, EiffelActivityStartedEvent, EiffelArtifactCreatedEvent, EiffelArtifactPublishedEvent, EiffelConfidenceLevelModifiedEvent.
Not sure if "verdict" is good name for activities in general. It makes perfect sense for "checking activities" (or for activities that can be seen as predicates). And for those we should consider INCONCLUSIVE as a possible value. For other activities it is at least not a common terminology.
Is the name the tail of the URI, or is something indicating "type" of log. Test activities typically creates logs of various kinds: T&E, Syslog, ... |
| #### data.outcome.verdict | ||
| __Type:__ String | ||
| __Required:__ Yes | ||
| __Legal values:__ SUCCESS, FAILURE, ERROR, ABORTED, TIMEOUT |
There was a problem hiding this comment.
If we map those to ones that are available in Jenkins, then we could also add UNSTABLE. Which mean activity was able to run until the end, but verification check result is different from expected
There was a problem hiding this comment.
I'm really struggling with this. I don't want to tie into Jenkins just for the sake of it (see below), and I think UNSTABLE is a really poor term. I'd much rather go with actual standards rather than de facto standards (and I'd argue that this isn't even that).
But this is an area where I'm having a hard time coming up with really good terminology. Arguably we should use FAULT, ERROR and FAILURE, but the way they're defined (see e.g http://programmers.stackexchange.com/questions/184412/whats-the-difference-between-fault-error-and-defect) I don't think helps in this case.
Regardless what we propose, we should add crystal clear explanations of each value in the description.
|
Overall we need to check for several things:
|
|
Legal values: do we want to validate them? As far as feasible (and using JsonSchema enums it should be), yes. |
Also added clarification of legal values where applicable. Left certain values in ActivityFinished.data.outcome.verdict undefined to solicit feedback and suggestions, as per ongoing pull request discsussion.
| SUCCESS signifies that the activity was concluded and the outcome matched expectations. | ||
| ??? signifies that the activity was concluded, but the outcome did not match expectations. To exemplify, a compilation job was successfully invoked, but compilation failed. | ||
| ???? signifies that the activity could not be successfully executed. To exemplify, a compilation could not be invoked, e.g. due to misconfiguration or environment issues. | ||
| ABORTED signifies that the activity could aborted before it could be concluded. |
There was a problem hiding this comment.
activity could aborted => activity was aborted
There was a problem hiding this comment.
Good catch. Fixed.
| 1. EiffelConfidenceLevelModifiedEvent | ||
| 1. EiffelArtifactPublishedEvent | ||
| 1. [EiffelActivityStartedEvent](./eiffel-vocabulary/EiffelActivityStartedEvent.md) | ||
| 1. [EiffelActivityFinished](./eiffel-vocabulary/EiffelActivityFinished.md) |
There was a problem hiding this comment.
EiffelActivityFinished -> EiffelActivityFinishedEvent
EiffelActivityFinished.md -> EiffelActivityFinishedEvent.md
Based on comments in pull request.
| @@ -0,0 +1,40 @@ | |||
| # EiffelActivityFinishedEvent | |||
| The EiffelActivityFinishedEvent declares that a previously queued activity (declared by [EiffelActivityQueuedEvent](./EiffelActivityQueuedEvent.md)) has finished. | |||
There was a problem hiding this comment.
This indicates that one could skip the started event which is not wanted behavior since we have the dequeued event for that case. Suggest to remove "previously queued" or change to "previously started".
Clarified that the finished activity should previously have been started, not just queued.
* Add default issue and pr template * See issue eiffel-community/community#13
No description provided.