Page History

1. CLI
   1. Checkout repo
   2. Create bugfix branch
   3. (other) Find (or make own) a gh extension creating skeletal framework like creating a new project, and we can use that to create a simple project.
      1. Where extensions live
      2. What environment is needed
      3. Basic engineer and build system github action workflows
      4. ex: gh create-component <project_name>
      5. Can create addition --type flag for like IOC, Matlab, Python etc.
2. GH Actions
   1. Trigger workflow on check in to any branch
   2. Call out to build system with repo/branch for the appropriate container (build environment)
      1. Which calls the component database and checks out repos and builds the repos
   3. Report
   4. Run any tests
      1. Installing build results to some place
      2. Run whatever tests available specific to component (Like unit tests, integration tests)
   5. Record to the component databases
      1. branches under development
      2. If testing passed, code review passed
      3. Preferred test location Maybe here?
   6. Record to the deployment database
      1. For each active branch under development or production
      2. Preferred test location Maybe here?.
   7. Create a pull request
   8. Handle approval of pull request
      1. If require coordination with a PAMM, then schedule a job
      2. Deployment database recording of start stop success failure
         1. If successful, remove candidate tag, update issue
         2. if fails, remove entire tag, install the known good tag

Current:

1. Do step 'CLI - c.' (other) Find (or make own) a gh extension creating skeletal framework like creating a new project, and we can use that to create a simple project.

   Jira
   server SLAC National Accelerator Laboratory serverId 1b8dc293-975d-3f2d-b988-18fd9aec1546 key EEDSWCM-77

2. Think about if we host the github runner on self-host organization level, that it will be responsible for fulfilling all of the requests of developers triggering the workflow. 
   1. This can be problematic if requests are overwhelming the build system which can lead to a large wait time for builds
   2. Instead maybe we want a 'build system' that gets run each time a developer requests something, in that case we would have to make a runner self-hosted on each repo. Or we can keep the runner on github since we have enterprise, the only concern would be if there are any external limitations (i.e. any restrictions on what we can run like if a test can only be ran on certain hardware)
3. Complete buildroot github action workflowWhile we wait for kubernetes cluster [EEDSWCM-79] Self-hosted github actions runner - SLAC JIRA (stanford.edu)