Page History

1. Build Workflow example
   1. TODO: Make a flow chart ppt when done creating
   2. Overall plan: runner checks out repo to /sdf/group/ad/eed/ad-build/<user>/ → runners request to backend build cluster to start new build container -> builder pod starts a new container on our ad-build cluster -> write log to database
   3. Steps broken down:

      1. Runners request to backend build cluster, uses a rest api to send a POST request to 'build' endpoint with data like this:
         

         Code Block
         language bash linenumbers true collapse true
         curl -X POST \ 'https://accel-webapp-dev.slac.stanford.edu/api/cbs/v1/component/build' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "organization": "str", "componentName": "str", "branchName": "str", "actionUser": "str" }'

      2. Backend builder pod talks to component database, grabs the build environment based off the organization, componentName and branchName

      3. Backend builder pod then starts the build environment using build-deployment.yml with parameters (componentName, branchName, imageName, actionUser, buildInstructions)

         1. Use Declarative Management of Kubernetes Objects Using Kustomize | Kubernetes to configure the build-job.yml for the component
         2. build-job.yml will be a job with a volumeMount to s3df-dev-container-ad-group, and template parameters to label the container (componentName-branchName), and provide image name, and command to start build (buildInstructions)
      4. backend builder pod then logs to branches_in_development.
      5. backend builder pod sends the name of the build container thats running, back to runner,
      6. runners last job is to print the filepath to where the container is being built, and othe useful info like 'status'
      7. if triggered by action (push to main/ pull request), then we want to provide the Report to user which can include
         1. filepath to user of the build output
         2. status (successful built / fail).
         3. time duration
      8. LAST STEP: have the build container push its artifact somewhere where a test container can download the artifact then do its testing.

core-build-system notes

1. Example: Adding fields to the component schema, as well as the api. What classes to change:
   1. Rest API:
      1. controller/ComponentController.java → @RestController() 
         1. This is where you define the api commands
            1. @PostMapping, @GetMapping, @DeleteMapping
      2. mapper/ComponentMapper.java → @Mapper
         1. This is only made when you have a field that has fields of its own, and you need to map it to main schema
   2. Service:
      1. This is the backend logic that the rest api commands call
      2. service/ComponentService.java → @Service()
         1. ex: create() - check no conflict, check dependencies, then create the component and save to mongodb, then return the created component id back to user
   3. Repository:
      1. This is backend logic that extends MongoRepository for functions regarding the repository like 'boolean existsByName(string name)"
         1. repository/ComponentRepository.java
   4. Schema:
      1. model/Component.java
      2. dto/ComponentDTO.java → @Schema()
         1. This is where you define the db document schema
      3. dto/newComponentDTO.java →@Schema()
         1. What's the difference between componentDTO and newComponentDTO?
   5. Exception Handling:
      1. exception/ComponentAlreadyExists → @ResponseStatus
      2. exception/ComponentNotFound→ @ResponseStatus

Backend meeting with Claudio/Jerry/Patrick 5-28-24

...