[BUILD] All tests passing!

- Also updated README.md
- Added a scheduled run of the workflow so the cache never expires
- Change cache key to accurately reflect contents
- Removed ./runtime build from test.sh
- Removed unnecessary installations of some packages

.github/workflows/pull_request_ci.yml

@@ -7,12 +7,15 @@ name: CI
 # Under what conditions do we run this workflow? Either
 # a) It is a commit on a pull request on a branch to be merged into master
 # b) It is a push to master (which only happens when we close a pull request)
+# c) It's 10:45 UTC on the 1st, 8th, 15th, 22nd, or 29th of a month (to prevent the cache from expiring)
 on:
   pull_request:
     branches: [master]
     types: [opened, synchronize]
   push:
     branches: [master]
+  schedule:
+    - cron: '45 10 1,8,15,22,29 * *'
 
 # Here is the list of jobs that this workflow will run. There is only one job.
 jobs:
@@ -28,27 +31,27 @@ jobs:
         uses: actions/checkout@v3
         with:
           submodules: 'recursive'
-          
-    # Next we install a bunch of dev packages that are needed to build Runtime
+
+      # Next, we install dev packages needed for Runtime
       - name: Install dev packages
         run: |
-          sudo apt-get update
           sudo apt-get install -y \
           python3-dev \
-          python3-pip \
           clang-format \
           protobuf-compiler \
           libprotoc-dev
-          
-      # Next we install Cython using pip
+      
+      # Next, we install Cython
       - name: Install Cython
         run: |
-          python3 -m pip install Cython
+            python3 -m pip install Cython
         
-      # The next three steps do the following:
-      # Give the program "tar" root permissions
-      # Retrieve cached files associated with the protobuf-c library, if they exist
-      # Take away root permission from the "tar" program
+      # The next steps steps do the following:
+      #  
+      # 1) Give the program "tar" root permissions
+      # 2) Retrieve cached files associated with the protobuf-c library, if they exist
+      # 3) Take away root permission from the "tar" program
+      #
       # We need to do this because the Cache Action uses "tar" to restore cached files
       # into the runner. However, the cached files need root permission to get restored.
       # Thus, we need to give tar root permissions to do the cache restoration, then 
@@ -69,20 +72,20 @@ jobs:
               /usr/local/include/protobuf-c
               /usr/local/include/google
           # This is the name (key) of the cache that we look for each time
-          key: libprotobuf
-      - name: Take tar root permissions away
+          key: libprotobuf-c
+      - name: Take away tar root permissions
         run: |
-          sudo chown runner:runner /usr/bin/tar && sudo chmod u+s /usr/bin/tar
+          sudo chown runner:runner /usr/bin/tar && sudo chmod u+x /usr/bin/tar
 
-      # This if statement determine whether the cache lookup was a hit (true) or miss (false)
+      # This if statement determine whether the cache lookup was a hit (true) or miss (not true--idk, false doesn't work)
       # If the cache lookup hit, we just run "sudo ldconfig" to tell the linker where to look for
       # protobuf-c files. If the cache lookup missed, we have to install protobuf-c from scratch
       # See https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#using-the-output-of-the-cache-action
       - if: ${{ steps.cache-protobuf-c.outputs.cache-hit == 'true' }}
         name: Run ldconfig
         run: |
             sudo ldconfig
-      - if: ${{ steps.cache-protobuf-c.outputs.cache-hit == 'false' }}
+      - if: ${{ steps.cache-protobuf-c.outputs.cache-hit != 'true' }}
         name: Install protobuf-c
         run: |
             wget https://github.com/protobuf-c/protobuf-c/releases/download/v1.4.1/protobuf-c-1.4.1.tar.gz
@@ -97,4 +100,4 @@ jobs:
       # And finally, we test Runtime
       - name: Test
         run: |
-          ./runtime test integration/tc_71_5
+          ./runtime test

README.md

@@ -1,4 +1,4 @@
-# PiE Runtime [![Build Status](https://travis-ci.org/pioneers/runtime.svg?branch=master)](https://travis-ci.org/pioneers/runtime)
+# PiE Runtime [![Build](https://github.com/pioneers/runtime/actions/workflows/pull_request_ci.yml/badge.svg)](https://github.com/pioneers/runtime/actions/workflows/pull_request_ci.yml)
 
 Welcome to the PiE Runtime repo! This README will only cover how to install, build, and run Runtime. If you want to learn more info about how Runtime works, or are a new member, please check out our wiki https://github.com/pioneers/runtime/wiki.
 
@@ -23,18 +23,16 @@ Runtime can be divided into a few neatly containerized parts:
 
 In addition to these parts, there are a number of configuration files for Runtime to manage the various tools that we use. They are listed here, with a brief explanation about what they do:
 
-* `.dockerignore`: this file lists out all of the directories, files, and other information that we do not want to include when building Runtime's Docker image.
 * `.gitignore`: this file lists out all of the directories and files that we don't want in our Git repository. This includes things like executables, build files, and `.DS_Store`.
 * `.gitattributes`: this file is purely for aesthetic purposes. It tells Github which files to exclude when calculating the repository language makeup you see in the repo (below the "Contributors" section in the sidebar on the web page that you're probably looking at right now).
-* `.travis.yml`: this file tells Travis (the continuous integration tool that we use) what to run when checking if Runtime is working properly before a new feature is merged into the master branch. It is essentially responsible for running the integration tests and for updating Runtime's Docker image.
-* `docker-compose.yml`: this file is used to describe to the `docker-compose` command what to run.
+* `.github/workflows/pull_request_ci.yml`: this file outlines the steps taken by the Github Action that we use to test our code before we release Runtime. See our most recent CI builds [here](https://github.com/pioneers/runtime/actions/workflows/pull_request_ci.yml)!
 * `runtime`: this file is a convenience shell script that makes it easy to call the various other shell scripts in our directory, which you will read more about later.
 
 This README will not go into each of these parts into exhaustive detail; explanations for each part can be found in the corresponding folder's README in the repo as well as [our wiki.](https://github.com/pioneers/runtime/wiki)
 
 ## Dependencies
 
-Runtime is designed to be used on the Raspberry Pi, and with a distribution of Linux called Raspbian, a slight variant of the extremely popular Debian. We tested Runtime to work well on Linux systems. If you do not have a Linux system, please instead use Docker (which might even be easier than using Linux). The major benefit of using Docker is you can skip this entire dependency section. To learn more about it, check out the README in the `docker/` folder.
+Runtime is designed to be used on the Raspberry Pi, and with a distribution of Linux called Raspbian, a slight variant of the extremely popular Debian. We tested Runtime to work well on Linux systems. Only some parts of Runtime work on macOS and may require different commands to compile; no parts of Runtime can operate on Windows. Please use a Linux machine or (preferably) a Raspberry Pi to run Runtime!
 
 ### Commonly Used Tools
 
@@ -60,21 +58,19 @@ Runtime has the following third-party library dependencies:
 
 #### Installing Google Protobufs and `protobuf-c`
 
-1. From `https://github.com/protocolbuffers/protobuf/releases`, download the latest `protobuf-cpp-<release>.tar.gz` and extract it (for help, click [here](#extract))
-2. From `https://github.com/protobuf-c/protobuf-c/releases` download the latest `protobuf-c-<release>.tar.gz` and extract it (for help, click [here](#extract))
-3. You may need to install some tools (`libtool`, `pkg-config`, `g++`). To install a tool you don't have, run `sudo apt-get -y install <tool-name>`, replace `<tool-name>` with what you want to install.
 
-4. `cd` into the folder for `protobuf-cpp-<release>.tar.gz` and run:
-	1. `./configure`
-	2. `make` (this takes a long time)
-	3. `sudo make install`
-	4. `sudo ldconfig`
-5. `cd` into the folder for `protobuf-c-<release>.tar.gz` and run:
+1. From `https://github.com/protobuf-c/protobuf-c/releases` download version 1.4.1, i.e. [`protobuf-c-1.4.1.tar.gz`](https://github.com/protobuf-c/protobuf-c/releases/download/v1.4.1/protobuf-c-1.4.1.tar.gz) and extract it (for help, click [here](#extract))
+2. You may need to install some tools (`libtool`, `pkg-config`, `g++`). To install a tool you don't have, run `sudo apt-get -y install <tool-name>`, replace `<tool-name>` with what you want to install.
+
+3. To install Google Protobuf, run:
+    1. `sudo apt-get -y install protobuf-compiler`
+    2. `sudo apt-get -y install libprotoc-dev`
+4. To install `protobuf-c`, first `cd` into the folder for `protobuf-c-<release>.tar.gz` and run:
 	1. `./configure`
 	2. `make`
 	3. `sudo make install`
 	4. `sudo ldconfig`
-6. (optional) To view `protobuf-c` documentation:
+5. (optional) To view `protobuf-c` documentation:
 	1. Install `doxygen`: `sudo apt-get -y install doxygen`
 	2. Repeat steps 5.i and 5.ii from above in the `protobuf-c` directory, then do `make html`
 	3. Then navigate to that directory in Explorer/Finder and open the `html/index.html` file by double clicking on it
@@ -90,26 +86,22 @@ Then, extract the files with
 
 You might need to install `wget` and `tar` with `sudo apt-get -y install wget tar`.
 
-### Installing ncurses for Shared Memory UI
-The Shared Memory UI allows the user to have a real-time view of data flowing in and out of shared memory.
-This is analogous to the "shm_cli" among dev_handler_cli, executor_cli, and net_handler_cli.
-Note that the UI is used in development only as a debugging tool and should not be used in production.
-The command below will install ncurses on Raspbian / Debian machines:
+### Installing `ncurses` for Shared Memory UI
+
+The Shared Memory UI allows the user to have a real-time view of data flowing in and out of shared memory. This is analogous to the "`shm_cli`" among `dev_handler_cli`, `executor_cli`, and `net_handler_cli`. Note that the UI is used in development only as a debugging tool and should not be used in production. The command below will install `ncurses` on Linux machines:
 
 	sudo apt-get -y install libncurses5-dev libncursesw5-dev
 
 ### Installing Clang Format
-Clang Format is used to format code to comply with our  [code style](https://github.com/pioneers/runtime/wiki/Project-Conventions). Code that is not formatted with Clang cannot be merged into master. After installing, use the runtime script to format code. (See `runtime format`)
-```
-sudo apt-get -y install clang-format
-```
+Clang Format is used to format code to comply with our [code style](https://github.com/pioneers/runtime/wiki/Project-Conventions). Code that is not formatted with Clang cannot be merged into `master`. After installing, use the runtime script to format code. (See `runtime format`)
+
+    sudo apt-get -y install clang-format
+
 ## Runtime Script and Usage
 
 We use the bash script `runtime` in this root directory as the entrypoint to our code. You can call it with `./runtime <args>` in this folder. However, you can also have it be callable from any directory by adding it to your `PATH` variable. This can be done automatically adding the following line to your `~/.bashrc` file:
 
-```
-export PATH="$PATH:<path to runtime folder>"
-```
+    export PATH="$PATH:<path to runtime folder>"
 
 Then either close and reopen the terminal, or do `source ~/.bashrc`.
 
@@ -122,6 +114,7 @@ If you now type `runtime` it will list all the possible subcommands you can run.
 * `flash`: will flash an Arduino as a Lowcar device
 * `clean`: will remove all artifacts generated when building or running Runtime
 * `update`: waits for new `runtime.zip` to appear in `/tmp` and then will unzip it and reboot the robot
+* `status`: will display the currently running processes under the `ubuntu` user (to list active Runtime processes)
 
 ## Authors
 

dev_handler/dev_handler.c

@@ -10,8 +10,6 @@
 #include "../shm_wrapper/shm_wrapper.h"
 #include "message.h"
 
-#include <sys/stat.h> // *************************************************************************************
-
 /**
  * Each device will have a unique port number.
  * For example, if there is only one Arduino connected, it will (probably) appear as

scripts/test.sh

@@ -67,9 +67,6 @@ function run_tests {
 # installs function clean_up as SIGINT handler
 trap 'sigint_handler' INT
 
-# build all of Runtime
-./runtime build
-
 # replace the logger config with the production config
 mv logger/logger.config logger/logger.config.orig
 cp -p tests/logger.config logger/logger.config