...
- Example: Adding fields to the component schema, as well as the api. What classes to change:
- Rest API:
- controller/ComponentController.java → @RestController()
- This is where you define the api commands
- @PostMapping, @GetMapping, @DeleteMapping
- mapper/ComponentMapper.java → @Mapper
- This is only made when you have a field that has fields of its own, and you need to map it to main schema
- Service:
- This is the backend logic that the rest api commands call
- service/ComponentService.java → @Service()
- ex: create() - check no conflict, check dependencies, then create the component and save to mongodb, then return the created component id back to user
- Repository:
- This is backend logic that extends MongoRepository for functions regarding the repository like 'boolean existsByName(string name)"
- repository/ComponentRepository.java
- Schema:
- model/Component.java
- dto/ComponentDTO.java → @Schema()
- This is where you define the db document schema
- dto/newComponentDTO.java →@Schema()
- What's the difference between componentDTO and newComponentDTO?
- Exception Handling:
- exception/ComponentAlreadyExists → @ResponseStatus
- exception/ComponentNotFound→ @ResponseStatus
- Testing:
- test/....../controller/ComponentControllerTest.java
- test/....../service/ComponentServiceTest.java
Proof of concept development
Used configMap to pass in information from backend to build container. So build container can echo the build parameters passed in
- Commands:
- kubectl create configmap build-config --from-file=build-request.
properties - kubectl describe configmaps build-config
- kubectl create -f build-config.yml
todo: Work on test project like test-ioc, with bom. claudio can use this to test
- we can make the lsit of components just have boost and epics for now
- Then we want to get to the point where a pod is executed and start_build.py can read the bom of the ioc
todo: Work on getting testing flow designed
- Unit tests firsts, the ones you can run right after the build
- may want a specific directory name that the container test script can run
- Come up with backend api for it, which just records to db i think,
- We can assume basic/unit tests are automatically ran if a build is started
Flow:
- User command CLI
$ bs run build
which does the build flow.- Pass to backend the component, branch, and user headers
- backend looks into component DB for the development image
- backend mounts
/mnt
at /sdf/scratch/ad/ad-build/
for downloading src code - backend mounts
/build
at /sdf/groups/eed/ad/ad-build/
for the build scripts - backend mounts configMap at
/config/build_config.json
for build request information - starts the build container and calls
start_build.py
start_build.py
then performs a build and outputs its results at the top of repo directory
start_build.py
will then call start_test.py
start_test.py
will then look into directories in the src code called /test/unit_tests/ and run those
Group meeting 6-6-24
Group Meeting 6-6-24 - LCLSControls - SLAC Confluence (stanford.edu)