Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 353350

Summary:	discuss mapping for Koji status codes
Product:	z_Archived	Reporter:	Ken Leung <plcnkl>
Component:	Mylyn	Assignee:	Mylyn Inbox <mylyn-inbox>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	plcnkl, swagiaal
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Ken Leung

2011-07-28 13:53:27 EDT

Build Identifier: 

I am trying to create a Mylyn Builds connector for Koji (Red Hat's in-house build system).  I noticed that there are Hudson specific status code built into Mylyn Builds core project, but I cannot match them with Koji's status code so I should be grateful for your kind assistance/advice on how to solve this status code mismatch issue.

For Koji, each build request will be treated as a task where each task may trigger multiple child tasks (which corresponds to an actual build) for different build targets (like fedora15i386, fedora15x86_64, redhatEnterprise6i386, etc.) or dependencies (like one must first build the source rpm before the actual rpm can be built).

In this case, Koji has the follow task status codes as well as build status codes:

task:
Free - Pending to be assigned to a builder machine.
Open - Building.
Closed - Completed successfully.
Cancelled - Cancelled
Assigned - Assigned to a builder machine, queued/waiting to be built.
Failed - Failed.

Build:
Building - Building.
Complete - Completed successfully.
Deleted - Deleted.
Failed - Failed.
Cancelled - Cancelled.

Reproducible: Always

Comment 1 Steffen Pingel

2011-08-09 09:29:59 EDT

The framework defines the following states: 

BuildState { QUEUED, RUNNING, STOPPED, BUILDABLE; }
BuildStatus { FAILED, UNSTABLE, SUCCESS, DISABLED, ABORTED; }

Can you suggest a mapping and let me know which states or statuses are missing? It seems to me that we would be able to represent the Koji states with the existing API fairly well.

Comment 2 Ken Leung

2011-08-09 14:35:19 EDT

Hi Mr. Pingel:

In this case, since I have access to both the build and task data, I can combine those koji status codes and map to the existing mylyn builds status code.

So the proposed mapping plan is:

mylyn builds             koji
build states             task status

QUEUED                   Assigned
RUNNING                  Open
STOPPED                  
BUILDABLE                Free

mylyn builds             koji
build status             task status

FAILED                   Failed
UNSTABLE                 -
SUCCESS                  Closed
DISABLED                 Cancelled
ABORTED

Notice that there are a few missing ones, I guess I need more understanding about Hudson's stopped and aborted status.  Are they caused by a build fail event?  Or are they user triggered (like cancel build)?

For the stopped status, my guess is I can set it as stopped if the build status is not null (in this case, when the build is running, should the build status be set as null?) , am I correct?

Comment 3 Steffen Pingel

2011-08-09 15:33:22 EDT

(In reply to comment #2)
> Notice that there are a few missing ones, I guess I need more understanding
> about Hudson's stopped and aborted status.  Are they caused by a build fail
> event?  Or are they user triggered (like cancel build)?

STOPPED means that a build has completed regardless of its result.

DISABLED means that a plan (job) is disabled and no builds will run. This state doesn't make much sense for builds.  

ABORTED indicates that a build was canceled by a user.

> For the stopped status, my guess is I can set it as stopped if the build status
> is not null (in this case, when the build is running, should the build status be
> set as null?) , am I correct?

Yes, I believe that is correct.

Comment 4 Steffen Pingel

2011-08-11 07:06:51 EDT

I'll mark this bug as resolved for now. Please feel free to reopen if this needs more discussion or file specific bug reports if the existing status codes should be extended.