Page History

...

1. User command CLI $ bs run build  which does the build flow.
   1. Pass to backend the component, branch, and user headers
   2. backend looks into component DB for the development image
   3. backend mounts /mnt  at /sdf/scratch/ad/ad-build/ for downloading src code
   4. backend mounts /build  at /sdf/groups/eed/ad/ad-build/ for the build scripts
   5. backend mounts configMap at /config/build_config.json for build request information
   6. starts the build container and calls start_build.py 
   7. start_build.py then performs a build and outputs its results at the top of repo directory
2. start_build.py  will then call start_test.py
3. start_test.py will then look into directories in the src code called /test/unit_tests/ and run those

Group meeting 6-6-24

...

• 1) Use docker image with all the dependencies baked into it
• 2) or create container that have repo download/install all dependencies with cmake maybe
• 3) Have a configuration file for user to use saying which dependencies he has, and the ad-build will create the docker image for you.

...

• then need 

...

• lets say we have ioc that depends on boost and epics, if we start with vanilla dev container like rocky9, what information do we need to have
• once the image is built dynamically, then transfer that to a registry, and developers can use that on s3df apptainer since it has full dependencies.
• Who will build the image dynamically? - To build on kubernetres isn't possible, may need to find alternative like buildah, or just use github?

...

• boost component
• epics component

...

• image with everything is installed, one for each environment
• has bin,lib,etc, everything with all dependencies installed with dependencies you chose
• with goal of having iocs run in containers

...

• We want to end up with an installer package

...

• we want to avoid users tweaking the database each time
• we can have users specify in bom:
  • os enviornments
  • startup sequence
  • components and tags
• then after it build, copy the built directory to build system registry, and the build image will be used as the developer image. All the same image build, run, and development.
• start scripts (start_build.py) will read the bom that the user specifies and go from there

...

• if a machine is down, then we have an error on a componet deployment, and we have component A is dependent on component B
• we can use ansible to deploy the run binary
• deployment is not a problem

...

• if we run on a container, we don't have to worry about 

...

• but we willl convince ernest and greg to move away from the shared filesystem and have everything in the container and MODERNIZE

...

• So where are the build results are going to go?
• We can have a convention/standard directory for build results (tarball) to go, and the backend starts a pod that will know to look in there
• the start_build.py should have build and unit tests, then copy over to build results registry

...

Group Meeting 6-6-24 - LCLSControls - SLAC Confluence (stanford.edu)