From 559ee37b82f735846a4413ae22c7b873862de6a9 Mon Sep 17 00:00:00 2001 From: Cole Poirier Date: Fri, 3 Apr 2020 12:19:27 -0700 Subject: [PATCH] Added section on build servers, process automation, cognitive load reduction. --- ...23_2020mar26_decoder_emulator_started.mdwn | 49 +++++++++++++++++-- 1 file changed, 46 insertions(+), 3 deletions(-) diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn index a82c742..a7c0476 100644 --- a/updates/023_2020mar26_decoder_emulator_started.mdwn +++ b/updates/023_2020mar26_decoder_emulator_started.mdwn @@ -671,9 +671,52 @@ and outputted c-code. This leaves me wondering, as I mention on the HDL list, if we can do the same thing with large sections of the POWER Spec. -# Build Servers - -TODO +# Build Servers, Process Automation, and Reducing Cognitive Load + +Over the past month, Jacob, and a new project member Cole, set up a new build +server for the project. The build server is an old computer that Jacob wasn't +using anymore, that he decided to make available to the project for running +continuous integration (CI) testing for the many modules and submodules of +the project. The build server is a gitlab test runner instance using a Docker +backend. As Luke has taken pains to make clear many times, very large and +complex python projects are guaranteed to fail without proper, extensive test +coverage. This new build server will allow us to automate the running, +monitoring, and reporting of these tests, giving us the ability to push a +commit and have it automatically "verified" as cohesive with the existing +codebase. Automating feedback, will help provide more confidence +to the engineers that their code isn't breaking some other functionality in +a codebase they are working on, and should also help improve the ease of +long-term maintainability of the code. The more we can automate the menial +tasks that have to be repeated frequently, and are important for success of +the project but are not related to progressing the engineering of the Libre-SOC, +the more productive project members can be. + +While we are in the early stages of the CI testing integration into our project +workflows, eventually Jacob should be able to simply push a commit on his Kazan +SPIR-V to LLVM-IR compiler, and continue working, automatically recieving +feedback on how well his new code integrates with his existing code. As a +result he can be more confident in his code-quality and also work a bit faster +because he no longer needs to take time out of his workflow to run the tests. +More significant than this however, is that the automation of continuous +integration testing significantly diminishes the probability that the project +will get out of sync, or become cluttered with erroneous test failures, +obscuring the clarity with which a project developer can view the codebase. +Automating this kind of more "administrative" work, reduces the overall +cognitive load on the project developers allowing them to allocate +proportionally more attention to the primary engineering aspects of the project. + +To help continue to ease such administrative burdens on the engineers, Cole is +working on a repository of setup automation scripts. The first script is one +that will replicate the setup of Jacob's build server, so that others who want +to contribute computational resources to the project may do so easily. Cole is +also working on a collection of modular scripts to automate the setup of the +development environment for the HDL workflow and the layout of the SOC, +including the installation of development branches of a substainal number of +very complex pieces of software. This should help ease the process of +onboarding new members to the project, especially some interns that we have +coming onboard in the next few months to do the layout of the chip. These +scripts will be available via the git.libre-riscv.org repository dev-env-setup, +at the following link **TODO ADD LINK TO REPO**. # Conclusion -- 2.30.2