Skip to main content

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

Jump to: navigation, search

Difference between revisions of "ALF/Build Service Flow Example"

< ALF
Line 10: Line 10:
 
  - Assumption is that tools would provide stable identifiers that are unique within their context.
 
  - Assumption is that tools would provide stable identifiers that are unique within their context.
  
== ALF requests a clean workspace from the Workspace Service ==
+
==ALF requests a clean workspace from the Workspace Service==
** Server identifier
+
* Server identifier
** SCM Configuration
+
* SCM Configuration
  
 
== Workspace Service notifies ALF of completion==
 
== Workspace Service notifies ALF of completion==
** Workspace location.
+
* Workspace location.
  
 
  * Get the source code by name (label/baseline/stream)
 
  * Get the source code by name (label/baseline/stream)

Revision as of 15:57, 5 June 2006

I'm going to work off of a hybrid of scenerio's A and B with some labels thrown in for good measure. One of the requirements is to: "Provide a diff report of every change to every code asset associated with the logical name." The key question here is "since when?" For now, I'm going to assume that the build system has the answer to that question since it definately could. I imagine it could come from other places as well. There is every possibility that I've massively misunderstood how service flows should be put together. Please correct me in that case.

I'm also leaving off some of the details. For instance, when a check-in is requested, a check-in message should probably be passed in to humor the SCM systems. I'm ignoring that kind of thing for now.

This flow assumes shared workspaces for build and scan, but they could be seperate.

Trigger: Unknown

- Would need to identify/imply the configuration SCM, the Build tool, scanning tool.
- Perhaps we have an association service that ties all these things together. A cross tool association repository is needed. Perhaps this is where Corona fits in.
- Assumption is that tools would provide stable identifiers that are unique within their context.

ALF requests a clean workspace from the Workspace Service

  • Server identifier
  • SCM Configuration

Workspace Service notifies ALF of completion

  • Workspace location.
* Get the source code by name (label/baseline/stream)
**ALF messages SCM service 1 with
*** Get (update)
*** A configuration
*** Location of the workspace.
  • Scan the Code
    • ALF messages Code Scan service with:
    • Scan Profile Name
    • Workspace Location
  • Code Scan service messages ALF as complete.
  • Do the build
    • ALF messages Build Service with:
      • 'Force Build'
      • Workspace Location
      • Name/Id of project / build profile
  • Build notifies ALF of completion with:
    • Status (success/fail/other)
    • List of new versions / stamps.
  • ALF ask Build When previous build was for:
    • This profile
    • This SCM configuration
    • Returns a date or label
  • ALF requests change log from SCM Service 1 with
    • Configuration (might just be workspace)
    • Changes since name or date
    • Changes up to name or date
    • Flag to get full diffs (for Kelly's requirement) (makes the report huge).
  • ALF notifies interested parties of the change log results (build is one, I'm sure there are others).
  • ALF requests baseline from the SCM Service 1 with:
    • A logical name
    • workspace location OR
    • Configuration and a date
  • ALF requests a check-in from SCM Service 2 with:
    • Location of generated artifacts

Back to the top