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 11: Line 11:
  
 
* ALF requests a clean workspace from the Workspace Service with
 
* ALF requests a clean workspace from the Workspace Service with
# Server identifier
+
** Server identifier
# SCM Configuration
+
** SCM Configuration
  
# Workspace Service notifies ALF of completion with
+
* Workspace Service notifies ALF of completion with
* 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 with:
  * 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 When previous build was for:
  * This profile  
+
  ** This profile  
  * This SCM configuration
+
  ** This SCM configuration
  * Returns a date or label
+
  ** Returns a date or label
  
# ALF requests change log from SCM Service 1 with
+
* ALF requests change log from SCM Service 1 with
  * 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 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 baseline from the SCM Service 1 with:
+
* ALF requests a check-in from SCM Service 2 with:
* A logical name
+
** Location of generated artifacts
* workspace location OR
+
* Configuration and a date
+
 
+
# ALF requests a check-in from SCM Service 2 with:
+
* Location of generated artifacts
+

Revision as of 15:54, 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 with
    • Server identifier
    • SCM Configuration
  • Workspace Service notifies ALF of completion with
    • 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