Preflight Checklist - D100 - Joseph

Preflight Checklist for Assignment Submission

Taking care with submissions is not just a school habit. Any paid work involves some point where the code you've written leaves your hands, and you are responsible for it functioning pretty much perfectly. This is obviously true if you're handing a project over to a customer, but even in the middle of development, one team member's sloppy work can stop everyone for hours.

Making good checklists and following them rigorously is how professionals avoid breaking builds. When you hand your homework in, we're expecting you to be as careful as you would on a large team, or deploying to a large number of customers, where the stakes are high.

We expect you to be careful, but this isn't a software engineering course, and we don't want to grade your ability to invent a procedure. In that spirit we're sharing two checklists to follow, that we believe should catch the most catastrophic simple mistakes.

Neither checklist is mandatory, but if you lose marks or receive a zero on an assignment, and the problem would have been caught by one of the checklist steps, don't be surprised if the answer is no. You can still ask, of course -- if it's the first time, and especially if you investigated and know or have a good guess what you did wrong, you could get part marks.

One thing you won't find out directly from this procedure is whether you edited one of the supplied source files. It's an instruction on every assignment but it's easy to miss, and the grader will probably give you 0 if you do it!

The checks are divided into a quick checklist, and a more thorough one.

The easy and (debatably) more obvious checks:

  • Check instructions for CMakeLists.txt to ensure the executable name is correct

  • Go into the repository root and run the minimum_checker

  • Run git status in the repository root to make sure there are no uncommitted files

  • Run git pull and git push to make sure your local repository is synced to the GitHub remote

  • Check the last commit time on GitHub and make sure it matches what you expect

  • Go through the grading criteria one-by-one and check that your program satisfies them -- pay particular attention here to notes about directory structure and naming

    It's easy to accidentally miss or misunderstand one of the

  • Run the specified checker from the grading criteria: for these CMake-based assignments, use the standard sequence mkdir build; cd build; cmake ..; make all to build the checker, and unless you are specifically told otherwise, run it from the build folder

The more interesting checks,

which will take a little longer, but mimic how the grader creates a new environment to run your code. This will catch some problems you won't find out about any other way:

  • Make a new (temporary) docker instance based on the CMPT 201 image -- you can use the same procedure as when you first set your original image up
    • If you don't want to add a new key to GitHub every time you do this, you could reuse the instance, but it's important that it's a different instance from the one you develop on -- at least delete your cloned repository after you're done
    • It is possible to script adding an existing private ssh key to the new instance, and it's a useful test of your shell skills, but be careful about it
  • Clone the repository into the new instance, using a different name. This catches a couple different kinds of build problems. The command will be something like git clone git@github.com:SFU-CMPT-201/your-repository.git custom-name -- note the extra parameter, custom-name, which tells git to use that folder name instead of the default, which is the repository name
  • Go into the repository root (custom-name or whatever you called it) and run the minimum_checker again
  • Build and run the checker again, according to the grading criteria
  • If you discover problems at this point, it's important to continue development in your regular instance, record properly, commit and push your changes. You can pull them into the second instance instead of cloning again, but don't change your development process mid-stream!
  • If everything looks okay, you can delete the temp docker instance -- if you are going to reuse it, I recommend at least removing the cloned repository. It should be as close to pristine as possible every time you use it

No check can be perfect, and there are still some situations that this won't capture. Some of them are known. For example, suppose you compute the home directory of a user by prepending "/home/" to the username. That's an understandable mistake, but if you make it you're not reading the documentation. This method trivially does not work for the root user on most systems, and the checker will probably catch the problem when doing final grading.

We won't generally change grades if the marks were lost for failures like this, because it's about the core material we're teaching. It's your responsibility to use the available documentation and develop your own functional tests as necessary, so please do be careful!