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.
Difference between revisions of "ALF/Build Service Flow Example"
< ALF
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This scenerio is a hybrid of Kelly's A and B scenrios with some labels thrown in for good measure. This scenerio expects there to be a clean build (fresh workspace), with some reports generated and generated artifacts checked in to a second, secure artifact repository distinct from the SCM containing the source. | |
| + | |||
| + | 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, we'll going to assume that the build system has the answer to that question since it definately could. 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. | 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. | ||
| Line 5: | Line 7: | ||
This flow assumes shared workspaces for build and scan, but they could be seperate. | This flow assumes shared workspaces for build and scan, but they could be seperate. | ||
| − | Trigger: | + | ===Trigger: Various=== |
| − | + | * 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. | |
| − | + | ** Maybe Corona fits in here? | |
| + | *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 | *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: | * 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 asks 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 | |
Latest revision as of 17:25, 5 June 2006
This scenerio is a hybrid of Kelly's A and B scenrios with some labels thrown in for good measure. This scenerio expects there to be a clean build (fresh workspace), with some reports generated and generated artifacts checked in to a second, secure artifact repository distinct from the SCM containing the source.
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, we'll going to assume that the build system has the answer to that question since it definately could. 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.
Contents
- 1 Trigger: Various
- 2 ALF requests a clean workspace from the Workspace Service
- 3 Workspace Service notifies ALF of completion
- 4 Get the source code by name (label/baseline/stream)
- 5 Scan the Code
- 6 Code Scan service messages ALF as complete.
- 7 Do the build
- 8 Build notifies ALF of completion
- 9 ALF asks Build Service when previous build was
- 10 ALF requests change log from SCM Service 1
- 11 ALF notifies interested parties of the change log results
- 12 ALF requests baseline from the SCM Service 1
- 13 ALF requests a check-in from SCM Service 2
Trigger: Various
- 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.
- Maybe Corona fits in here?
- 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 asks 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