Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will 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 17: Line 17:
 
* Workspace location.
 
* Workspace location.
  
* Get the source code by name (label/baseline/stream)
+
===Get the source code by name (label/baseline/stream)===
**ALF messages SCM service 1 with
+
*ALF messages SCM service 1 with
*** Get (update)
+
** Get (update)
*** A configuration
+
** A configuration
*** Location of the workspace.
+
** Location of the workspace.
  
* Scan the Code
+
===Scan the Code===
** ALF messages Code Scan service with:
+
* ALF messages Code Scan service with:
** Scan Profile Name
+
* Scan Profile Name
** Workspace Location
+
* Workspace Location
  
* Code Scan service messages ALF as complete.
+
===Code Scan service messages ALF as complete.===
  
* Do the build
+
===Do the build===
** ALF messages Build Service with:
+
* ALF messages Build Service with:
*** 'Force Build'
+
** 'Force Build'
*** Workspace Location
+
** Workspace Location
*** Name/Id of project / build profile
+
** Name/Id of project / build profile
  
* Build notifies ALF of completion with:
+
===Build notifies ALF of completion===
** Status (success/fail/other)
+
* Status (success/fail/other)
** List of new versions / stamps.
+
* List of new versions / stamps.
  
* ALF ask Build When previous build was for:
+
===ALF ask Build Service when previous build was===
** This profile  
+
* For this profile  
** This SCM configuration
+
* For some SCM configuration
** Returns a date or label
+
* Returns a date or label
 +
* It may make sense to have a historian service within ALF that manages some of this or to ask SCM.
  
* ALF requests change log from SCM Service 1 with
+
===ALF requests change log from SCM Service 1===
** Configuration (might just be workspace)
+
* Configuration (might just be workspace)
** Changes since name or date
+
* Changes since name or date
** Changes up to name or date
+
* Changes up to name or date
** Flag to get full diffs (for Kelly's requirement) (makes the report huge).
+
* 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 notifies interested parties of the change log results===
 +
* Build is interested, I'm sure there are others
  
* ALF requests baseline from the SCM Service 1 with:
+
===ALF requests baseline from the SCM Service 1===
** A logical name
+
* A logical name
** workspace location OR
+
* workspace location OR
** Configuration and a date
+
* Configuration and a date
  
* ALF requests a check-in from SCM Service 2 with:
+
===ALF requests a check-in from SCM Service 2===
** Location of generated artifacts
+
* Location of generated artifacts

Revision as of 16:00, 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

  • Status (success/fail/other)
  • List of new versions / stamps.

ALF ask Build Service when previous build was

  • For this profile
  • For some SCM configuration
  • Returns a date or label
  • It may make sense to have a historian service within ALF that manages some of this or to ask SCM.

ALF requests change log from SCM Service 1

  • 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 interested, I'm sure there are others

ALF requests baseline from the SCM Service 1

  • A logical name
  • workspace location OR
  • Configuration and a date

ALF requests a check-in from SCM Service 2

  • Location of generated artifacts

Back to the top