Using GitHub

Pushing to GitHub

To make sure your GitHub repo is setup, try editing the README.md file locally. You should then be able to commit and push your changes back to the GitHub server.

How you will commit and push will depend on your client:

• On GitHub Desktop, the steps are:

  1. Click the “Changes” tab
  2. Check all the files you want to commit (usually it’ll be all of them)
  3. Type something where it says “Add information about the purpose of this change”
  4. Click “Commit to main”. This will make the commit locally.
  5. Then on the top bar you should see a “Push origin” button, which will push the changes to the GitHub server.

• If you’re using the command line (either Terminal on Mac or Git Bash on Windows), you need to add the files you want to commit then commit and finally push. For example, if you changed your README file and want to send the changes to GitHub, you would:

   git add README.md
   git commit -m "Updated README file"
   git push origin main
  

You need to always make sure you are pushing your code to the GitHub server or we will not be able to view it or grade it. You can double-check to make sure that the code was pushed by going to the GitHub website and checking that your repository shows the updated code files.

Viewing Build Warnings and Errors on GitHub Actions

Because TAs may run your games on either PC or Mac, we’ve setup continuous integration on your repo. Every time you push updated files, GitHub Actions will attempt to build your code on both PC and Mac, and report any errors or warnings back to you.

The GitHub Actions build will only build any lab(s) affected by a push. For example, if you only change files in Lab02, it will NOT also build your Lab03 code. Because of this, the best way to view the result of your most recent build on a particular lab is to navigate to that lab’s subfolder and GitHub and view the action result from that. This process is outlined below.

To view the results from GitHub Actions:

1. Go to the GitHub page for your repository.
2. Decide which lab you want to view the build result for and click on its folder on the GitHub site. For example, if you want to review the results of Lab01, you would click on Lab01:
3. When you get to a lab’s page, immediately above where it lists out the files in the folder, you will see information about the last commit. On the right, you will see the time of the commit (like “3 hours ago” in the image below), and immediately to the left of it you will see a badge: The badge can be one of the following:
   • Green check - This means the build succeeded (as in, it compiled on both Mac and Windows) but DOES NOT say anything about whether or not there are warnings you should fix for an A.
   • Red X - This means the build failed for some reason. This could mean that Lab 12 failed to compile, or it could mean that one of the other labs modified in the same push failed to compile. (This is one reason why it’s a good habit to not push across multiple labs at the same time).
   • Yellow circle - This means that the build is currently in progress
4. Clicking on the badge will show a breakdown of all the different actions, like this: In this example, notice how it says “All checks have passed” AND it says 6 successful checks. If you view all the 6 build items (you may have to use the scroll bar), you will see that all 6 have green checkmarks. This means not only did the code compile on both platforms, there are no warnings to fix as part of the code review. Keep in mind, however, this doesn’t say anything about whether your game’s code actually works, since the GitHub Action doesn’t play your game.
   • Alternatively, you may see something like the result below, where there is one or more neutral check. This typically means that there is one more warning you should fix. The neutral checks are denoted by a grey square, so in this example, there was a clang-format issue:
   • Finally, if the build fails on one or more platform, you will see the failed checks listed out like this:
5. To view the detail about why the check(s) were neutral or failed, first click the “Details” button on one of those checks:
6. From here, scroll up until you see the “Summary” button on the left column and click on it:
7. If you scroll down on the summary page, you will see summaries describing what happened for both Mac and Windows, which will look something like this: For any items that have logs, you can click the down arrow to see more detail about that item.
8. There also annotations that you can view on this page that show the same information but in a different format:
9. While you usually will not need to, in some cases you may want to view the full build log as it may give more context. To do this, click on either the build-mac or build-windows job on the left, and you will see the log: The logs for clang-tidy are included as part of the build-windows job, so that’s where you’ll want to go to see the details for clang-tidy.

Although confirming your code builds on both platforms will catch many common errors, it still is possible that your game will not work correctly on the opposite platform. However, we are generally aware of the types of issues that may crop up. If your game does have platform-specific issues, you will be asked to fix them for your regrade to an A, but we won’t hold it against you for the purposes of verifying your specs for a B grade.

---