Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct typos #331

Merged
merged 2 commits into from
Nov 16, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion eiffel-syntax-and-usage/activity-linking.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ Pipeline executors can have different mechanisms for choosing when its activitie

A _fully event driven pipeline_ in Eiffel terminology is a pipeline where _all_ activities in it are triggered explicitly by Eiffel events. Those events could either come from earlier pipeline steps, or from other pipelines producing for example artifacts that this pipeline would be configured to trigger on.

A _fully orchestrated pipeline_ is completely controlled by a dedicated pipeline orchestrator, such as Jenkins Pipeline or Argo Workflows, and has no activities triggered by Eiffel events. A fully orchestrated pipeline is probably often initiated by a source change in some SCM system, and that source change is then propagated to the pipeline orchestrator through some non-Eiffel-event channel (e.g. an Github web hook or a Gerrit stream-event)
A _fully orchestrated pipeline_ is completely controlled by a dedicated pipeline orchestrator, such as Jenkins Pipeline or Argo Workflows, and has no activities triggered by Eiffel events. A fully orchestrated pipeline is probably often initiated by a source change in some SCM system, and that source change is then propagated to the pipeline orchestrator through some non-Eiffel-event channel (e.g. a Github web hook or a Gerrit stream-event)

None of the scenarios above is probably relevant for most of the Eiffel event users, but rather a combination of the two where a pipeline is often _triggered_ by an Eiffel event, and an orchestrator deals with controlling (at least parts of) the pipeline. Such triggers could for example be SCM events ([SCC][SCC]/[SCS][SCS]) or artifact events (e.g. [ArtC][ArtC]/[ArtP][ArtP]/[CLM][CLM]).

Expand Down
2 changes: 1 addition & 1 deletion eiffel-syntax-and-usage/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -151,4 +151,4 @@ An _occurrence_ is the capture of a statement of fact during the execution of a

### Pipeline

A _pipeline_ is an ordered set of [activities](#activity) often triggered by a [source change](#source-change) being created or [submitted](#submit). 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 an hierarchical connection to the pipeline activity.
A _pipeline_ is an ordered set of [activities](#activity) often triggered by a [source change](#source-change) being created or [submitted](#submit). 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.