Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

ALF/Vocabularies/SCM Vocabulary/POCUseCases

< ALF

Proposed POC use case 1: Most Simple Continuous Integration Build

Description:

The most basic continuous integration build scenario is provided. A developer checks in a file, causing a build to initiate. A full copy of the affected stream is populated into an empty workspace as designated by the build. The build is performed. Notification that the build is completed is provided as an ALF event.

Steps:

1. Developer checks in code within their versioning client.

2. Versioning provider fires an ALF Stream Changed event

3. ALF Event Manager receives Stream Changed event.

4. ALF Event Manager initiates an ALF Service Flow "Continuous Integration Build"

5. The Continuous Integration Build service flow facilitates the remainder of the steps:

6. ALF requests from the Workspace service a Workspace

Note: The service flow author has defined build locations.
Note: The Workspace service has been configured with known locations.
Note: Service flow author has to make conscious effort to put the Workspace service into the flow.

7. ALF requests from the Versioning service "Materialize a set of files in a workspace".

7a. Fires "Workspace update started" event (not relevant to this case)

7b. Fires "Workspace update completed" event

Note: At completion, Build service has access to a file system location where the source code has been placed
Note:  Consider callback mechanism.
Note:  Some considerable discussion on whether this is done by the Workspace or Versioning service.

8. ALF service flow continues when "Workspace update completed" event received

9. ALF requests from the Build service "Perform build"

10. Build service performs the build, and fires appropriate ALF events.

11. Build service fires "Build Completed" ALF event.

12. The service flow facilitates check in of build results. The assumption would be, the build results (executables etc) already are under source control, and at the end of the build we are creating a new version of each build result.

Some implementation pieces and parts (what needs to be built):
-	Service flow definition "Most Simple Continuous Integration Build"
-	Versioning service EVENT "Stream Changed"
-	Versioning service "Materialize a set of files in a workspace"
-	Workspace service EVENT "Workspace update started"
-	Workspace service EVENT "Workspace update completed"
-	Build service "Perform build"
-	Build service EVENT "Build Completed"
-	Build service check-ins build results using CreateNewVersions(FileSelection), AddAssets

Note: (12) could be extended to add the build result if it is not already under source control (using AddAssets), and create a new version if it is already under source control (using CreateNewVersions). How would this conditional be modelled by the service flow?

Back to the top