Architecture Refactoring - How to integrate external Continuous Integration Services

[Mtze]

We're currently discussing how to simplify the integration of external CI systems. The existing implementation of ContinuousIntegrationService was originally designed to work with Bamboo - and still has some methods that are not needed anymore. With the new LocalCI system and potential other stateless external CI systems it would make sense to refactor this interface.

In this thread we wanna kick off the discussion how to do the transition.

Things that need to happen

(from @bensofficial and @Mtze perspective) - Feel free to critique and amend the suggestion!)

1. New version of ContinuousIntegrationService interface

   • Methods
     • build(participation) -> ID The main trigger should be one simple build method that handles all the necessary details internally
     • status(participation) -> Status: Returns the current state of the build for participation
       • Open questions:
         • Should we store the external build state in the db and have an endpoint for the external ci to update the state OR always relay the request to the external CI without storing the state.
         • To Handle the artemis client build updates we need to have an endpoint that allows a CI system to update the state of the build. e.g. POST /api/programming/public/exercise/<exerciseid>/submission/<submissionid>/status
     • health(): Returns the health of the external system

2. The implementations of JenkinsService and LocalCIService need to be adapted to adhere to the new interface

   • LocalCI should be rather easy to implement as the concept is already "stateless"
   • The jenkins integration could be a bit harder as jenkins requires a build plan. Lets discuss what options we have here

3. Update for the result handling - Suggestion: Split the ingest of build results (e.g. Tests) and the ingest of build logs.

   • Endpoint to add test results to a participation: POST /api/programming/public/exercise/<exerciseid>/submission/<submissionid>/result (new DTO Type: ExternalBuildResult)

     public record ExternalBuildResult(
          CompletionState completionState, // Indicator if Build did complete successfull, failed because of test cases, or failed with compilation errors,  
          ZonedDateTime buildStartDate, // Time the CI system started the build execution 
          ZonedDateTime buildCompletionDate, // Time the CI system completed the build 
          List<TestCaseResult> testCaseResults, // Flattened list of JUnit results 
          List<StaticCodeAnalysisReportDTO> staticCodeAnalysisReports, 
      ) implements BuildResultNotification, Serializable {}

     public enum CompletionState {
       BUILD_FAILED,
       TEST_FAILED,
       SUCCESSFUL
     }

   • Endpoint to add build log to a participation: POST /api/programming/public/exercise/<exerciseid>/submission/<submissionid>/log (existing DTO Type List<BuildLogDTO>)

[Mtze]

Feedback from SK and programming meeting:

• Solve the Trigger issue first - The Result handling
• Get the Jenkins People on board
• It might be necessary to have a delete method in the trigger service to get rid of the build plan afterwards (for e.g. Jenkins)
• One Jenkins build plan for each build - Otherwise the some concurrency could kick in