This is a non-exhaustive, alphabetical list of terms used in the Eiffel vocabulary and its documentation.
These terms are either part of the event names in the Eiffel Vocabulary, or they are part of parameter names or values in the events. Users of Eiffel should be able to rely on these terms to be kept, unless a major change to event types are done.
An activity is any kind of action in a CI/CD system, normally triggered by an operation done in an SCM system, by a previous activity, or as part of an activity that focuses on performing tests. The Eiffel protocol declares events related to activities to describe what is going on, what has finished, when it happened and with what outcome.
Activities are hierarchical. Activities could be whole pipelines, or sequential or parallel parts thereof. Such pipeline parts could for example be build activities or test activities.
An activity could also be an SCM operation such as a manual code review or automated source change check.
Some activity types have their own specific events, such as EiffelTestCase*Events notifying test case executions, while others are more generic and can be notified using EiffelActivity*Events.
- EiffelActivityTriggeredEvent
- EiffelActivityStartedEvent
- EiffelActivityFinishedEvent
- EiffelActivityCanceledEvent
- EiffelTestCaseTriggeredEvent
- EiffelTestCaseStartedEvent
- EiffelTestCaseFinishedEvent
- EiffelTestCaseCanceledEvent
- EiffelTestSuiteStartedEvent
- EiffelTestSuiteFinishedEvent
Artifacts are items or software packages generated in a CI/CD pipeline, for example a built binary or a Docker image. An artifact should be possible to identify using a purl (package URL). Artifacts often refer to a composition stating exactly what versions of different software pieces where put together to form the artifact.
An artifact is often the subject of a test executed or a delivery performed within a CI/CD pipeline. An artifact can also be software package generated with the sole purpose to be used in a specific test scenario. For example when product software is combined with test harnesses. Such artifacts are also defined by compositions to record what versions of test harness software were used.
A composition is an immutable grouping of specific versions of artifacts and/or source changes. It is more or less the same as what is elsewhere sometimes referred to as a baseline, which can be explained as being a fixed reference point used for comparison. A composition is often defined with the purpose of enabling downstream artifacts to be generated. It gives full traceability on what software pieces that were used to generate the artifact, be it a product artifact, a test harness or some other kind of generated artifact.
A confidence level can be achieved for an artifact, a composition, or a source change. It can be used to annotate that the artifact, composition or source change has been tested up to a certain level, that it has reached a certain level of maturity, or that it has passed a certain criteria. Examples of confidence levels could be "smokeTestsOk", "releasable" or "released".
A confidence level can group other (sub) confidence levels of lower abstractions. For example the confidence level "allTestsOk" could summarize sub confidence levels called "unitTestsOk, "scenarioTestsOk" and "deploymentTestsOk".
Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
An Eiffel domain is an infrastructure topological concept, which may or may not correspond to an organization or product structure. A good example would be Java packages notation, ex. com.mycompany.product.component or mycompany.site.division. Domains can be used to implement Eiffel namespaces when different companies, business units, or similar exchange Eiffel events. An Eiffel event may include a member that specifies the event's domain association.
Also, keep in mind that all names are more or less prone to change. Particularly, it is recommended to avoid organizational names or site names, as organizations tend to be volatile and development is easily relocated. Relatively speaking, product and component names tend to be more stable and are therefore encouraged, while code names may be an option. You need to decide what is the most sensible option in your case.
An Eiffel environment defines the environment in which an activity is executed. Could be for example a host, node, service name/uri, a Docker image or some other kind of machine configuration definition.
An Eiffel event is a broadcast notification telling any consumer about an occurrence in the CI/CD pipeline. As opposed to a message, that is addressed to a certain receiver, an event is not aimed at a specific consumer. An event is also descriptive rather than prescriptive, meaning that it does not expect a certain action to happen but it instead notifies on actions performed.
An Eiffel event contains three types of information: A meta object providing contextual information about the occurence, a data object representing the specific occurrence, and a links object describing relationships between this event and previously sent events.
An event should not carry any data that is already provided by events sent earlier in the CI/CD pipeline. Instead those earlier events should be linked from this event, making it possible to aggregate all relevant data connected to the CI/CD pipeline execution.
A single occurrence may result in more than one event, for example a build activity being started would result in both EiffelActivityTriggeredEvent and EiffelActivityStartedEvent being sent if there is no build queue present.
More about what an event is supposed to be can be read in the event design guidelines.
A link is a directed connection between two events. With linked events you will get a directed acyclic graph of actions performed in your CI/CD pipeline. Links are also semantic, as each link has a type describing the relationship between the link source and its target. Having linked events enables generic data aggregations and visualizations to be implemented. Together with the timestamps provided in each event, the directed semantic links enable the possibility to create generic pipeline measurements and other analytics compilations.
More about links can be read in the links object documentation.
A source change is the unit of a review. It results in a single commit when merged to the Git repository.
A submit is the action of merging a source change to its intended target branch.
The terms below are not used in any events in the Eiffel protocol. They are added here to enable a homogenous and easy read of the protocol documentation. These terms are subject to change without notice if a better name is found or defined elsewhere. Their names should reflect the most commonly used terms elsewhere in the industry.
An occurrence is the capture of a statement of fact during the execution of a CI/CD pipeline. This might occur because of a source change being created/updated, an artifact being built, an upstream artifact being delivered, or any other activity relevant to a CI/CD pipeline.
A pipeline is an ordered set of activities often triggered by a source change being created or submitted. There exists no EiffelPipeline*Events, as the pipeline is to be considered an activity in itself. A pipeline execution could thus be expressed with EiffelActivity*Events, and its included sub activities would then have a hierarchical connection to the pipeline activity.