Learning about GitHub Actions

One of the features that comes with GitHub classroom is an autograder. This autograder is based around GitHub actions. This is one area where I do not have much experience with, so one of my summer to-dos is to learn enough about GitHub actions to make use of the the autograder.

Current Workflow

Currently for my data structures course, I make use of our internal submitter application created by my colleague Fardad. It is great for ensuring that the submitted work minimally compiles and passes some basic testing. The students log onto the schools linux cluster. From there they run the submitter command for the assignment. This command does the following:

• Copies the tester file into the student’s current directory (ensures it is the official tester)
• Compiles program with tester
• If program compiles runs the program
• Compares program output with correct output.
• If program output matches correct output, allows student to finalize the submission, at which point submitter emails professor with copy of student’s work and results

The submitter application is great and allows for flexibility in the way it compares correct output as well as due date options and so on. It is a pretty decent system. However, I don’t want to look at code submitted via email. Too many clicks and I can’t really give proper feedback. What I do is ask my students to put what they submit into their github repos. When they do this, I can write out my feedback to my students. I can use GitHub’s tools to highlight parts of the code that have errors or needs to be reconsidered. I love these tools… nothing in the education world match it.

Most of the time this works great. However, there is a disconnect between the submission via our internal linux cluster and the code on GitHub, the two aren’t always in sync. Sometimes students would submit and forget to push their code into their repo. Sometimes they would put in a last minute change on code in GitHub that actually breaks their program but because they have a submission it isn’t always caught. Ideally the code on GitHub and the code from submitter is the same but there is no way to guarantee this. What I want to do is to have only one code source… then what they submit and what I read are exactly the same.

GitHub Actions

GitHub actions is part of the CI/CD process being built into github. There are are many resources for learning about this all over the web. I’m mostly going to go through what I’ve tried, what works for me and the really that process of trying. I’m likely going to make mistakes and have holes in my understanding. If you see something wrong, let me know!

I’m going to use my tester and a solution for one of the questions from last semester to first figure out how to compile and run tester.

Much of the tutorials I see online focus on using JS, Node, or python and testing frameworks around that. For me, I’m using C/C++ so the process is a bit different.

Goal 1: compile and run

I started with the default workflow (the one you get with “setup workflow yourself button”) and modified it as follows… comments show the parts and what I’m trying to do:

# Modified from basic workflow for actions

name: CI

# These all seem reasonable did not change this section
# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:


# This next part I had to change a bit.
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # This one checkout the current repository... I will need to change this eventually (or add to it.
      # I want to pull from multiple repositories.  Good enough for now
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Did not change this.
      # Runs a single command using the runners shell
      - name: Compile
        run: c++ a1q3tester.cpp majelem.cpp timer.cpp -std=c++0x -o a1

      # First time I did this I just had a1, forgot to specify path and once I did it this worked.
      # Runs a set of commands using the runners shell
      - name: Run
        run: ./a1

Results!

In my first run I had used the exe name as run command and forgot about search path so it failed.. but after fixing that it worked!

Build summary

Details!

Day 1 goal was successful! I have a bit of better grasp on how actions work. Day 2 goal: Get the run to fail if a test does not pass. Not sure how I will do this just yet. I’m thinking testing return from exe? If you have any ideas about this let me know!