Contents:

Introduction

To turn in homework N, all that you need to do is (1) commit your changes; (2) tag that version as hwN-final, where N is the current assignment number; and (3) push that version to Gitlab. (If you are working at the command-line, remember to include the --tags argument to git push.)

While the above is sufficient if all is well, we strongly recommend you validate your submission by ensuring that it correctly compiles and runs the tests successfully on GitLab or attu. Validating your code checks it for common errors, such as forgetting to add a file that you created or checking in code that compiles on your local machine but not with the compiler used for grading. Such errors could prevent you from receiving credit for your code, so you should always validate your assignment before you complete it. (However, validation is not guaranteed to catch all errors in your code. Reasoning and testing are also necessary.)

You can validate your assignment by checking the Continuous Integration result on GitLab or by running gradlew validate on attu — and making sure that it completes successfully! Below, we describe how to validate your code in these two ways.

Validating with GitLab

In this course, you can use GitLab's Continuous Integration tools to validate our code. Whenever you push your code to GitLab, it should run a job that validates the code after that commit. If validation fails, either because it did not compile, a test did not pass, or you did not include a required file, then you should receive an email about the failiure. It will include a message like this:

If you submit code that passes validation, then you will, by default, not see any email. However, not receiving an email is not a perfect indicator that the code is correct. It could be that there was a problem with GitLab that prevented it from running the validation job or there could be a problem with your email that prevented the error message from getting to you.

There are two options you can use to be certain that your code properly validated on GitLab: check the web site or set up emails on successful validation (recommended). These are discussed in the next two sections.

Checking the GitLab Site

You can look at all your build/pipeline results on GitLab at the following URL: https://gitlab.cs.washington.edu/cse331-19wi-students/cse331-19wi-MyCSENetId/pipelines

If the build is successful you should see an entry like this that says "passed": If you click on the "passed" label, you can see the specific task run, which in this case was "validate". Clicking on that will take you to a page that shows detailed output from task. This will be useful to examine in the case of errors.

Setting up Emails for Successful Validation

The other option is to tell GitLab to send you emails for successful validation as well. In this case, if you do not receive an email, then you will know that it was not a successful validation but instead a failure with GitLab or your email.

To set up email notifications of successful validation, go to your GitLab notification settings page. Find your project cse331-19wi-students/cse331-19wi-MyCSENetID. Next to it, there should be a dropdown. Select "Custom" from the options in the dropdown. You should then see a dialog like this:

Make sure that "Successful pipeline" is also checked as shown here.

Once you make this change, you should now receive email notifications indicating that validation succeeded. This will include a message like the following:

Dealing with GitLab Problems

GitLab is a useful and usually reliable service, but occasionally it fails. That is, occasionally your jobs may fail because of a GitLab problem rather than a problem with your code. The error message from the build will help you understand the source of the failed validation.

When you have a GitLab problem, please follow this process:
  1. Restart the job by browsing to the failed build and clicking the "Retry" button in the upper right.
  2. If the GitLab runner continues to fail in the same way, you should validate on attu instead, as describe below.
  3. If the attu command succeeds but the GitLab runner job fails, then send email to support@cs.washington.edu. Be sure to include the URL of your job that failed, such as https://gitlab.cs.washington.edu/cse331-19wi-students/cse331-19wi-MyCSENetID/-/jobs/452877, and also show the command you ran on attu and its output (as when reporting any problem with a command-line tool, cut-and-paste the output, don't take a screenshot).

Validating on Attu

You can also validate your code by running gradlew validate on attu — and making sure that it completes successfully! — using the commands below. These commands will make a complete, fresh copy of your CSE331 GitLab repository attu and then compile and run the tests in this copy. If you have forgotten to push some of your changes to GitLab or if there are other bugs, the validate step will help you catch at least some of these problems.

You can log in to attu via SSH from any machine. (Even if you are working on an Allen Center Linux machine you still need to SSH into attu.)

If you normally use Eclipse or IntelliJ rather than the command line, you will need set up an SSH key on your attu account in order to clone your repository there (just as you did to create a clone on your local machine). To do this, visit the GitLab SSH README and follow the directions on that page.

After you complete that, execute the following commands on attu

cd ~/
mkdir tmp   # or some other scratch directory name
cd tmp
git clone git@gitlab.cs.washington.edu:cse331-19wi-students/cse331-19wi-YourCSENetID.git
cd cse331-19wi-YourCSENetID
git checkout hwN-final
./gradlew validate

If you are prompted to enter a password for 'git@gitlab.cs.washington.edu' by the git clone command, then there is a problem with your SSH key for attu on GitLab. Try repeating the instructions on GitLab SSH README until this step works successfully without a password prompt.

What does this do?

This makes a fresh copy of your GitLab CSE 331 repository in a temporary directory and then switches to the version of the repository that you tagged with hwN-final to mark the final commit for hwN. (This is exactly what the course staff will do to retrieve the files for the assignment to grade them.) Then the ./gradlew validate step ensures that your implementation:

What is the result?

If validation was successful, you should see output that contains BUILD SUCCESSFUL.

If there is an error, the validate script will provide some information about what is wrong.

If the validate output indicates errors, you should fix them before the deadline, or you will lose points on your assignment.

To fix errors, it is extremely important that you DO NOT attempt to fix anything in the version of the repository you checked out on attu to run the validate step. You must (as in you ABSOLUTELY MUST) go back to your regular working copy, fix things there, push those changes, make a new hwN-final tag that points to this new commit, and push that tag. Then go back to attu and repeat the validate step from scratch. Remove any old copy of your repository you may have lying around on attu and clone a fresh copy of the repository and rerun the tests. If you try to patch the attu validate copy of the respository to fix bugs, you are very likely to introduce multiple branches into your repository that are not properly committed, leaving the GitLab copy of the repository in a very confused state.

Important: be aware that the validation script tests your code against your own test suite. Although by default we populate hwN.SpecificationTests with the public test suite, it is your responsibility to retain those tests in hwN.SpecificationTests if you want the validatation script to check your code against the public tests.

When you are done

Delete the copy of the repository on attu that you used for the validate tests. rm -rf cse331-19wi-YourCSENetID will do the job and will avoid leaving copies of your code lying around tying up space (and maybe, accidentially, visible to others).