Community
Participate
Working Groups
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
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.
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?
(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.
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.
