Assignment Submission

Contents:

• Turning in your assignment
  • Using a late day (turning in your assignment late)
  • Double-checking your assignment
• validate
  • GitLab runner pipeline problems

Turning in your assignment

To turn in your assignment:

1. Commit all your changes.
2. Push your changes to GitLab.
3. Push a hwN-final tag to mark the final commit for assignment N. You can do this from the command line or from the GitLab webpage.

   Command line:

   git tag -a -f hwN-final -m "HW N submission"
   git push --tags

   The same command works if the tag already exists and you want to move it. (CSE 331 policy states that you are not allowed to move a tag across days.)

   GitLab:

   Browse to https://gitlab.cs.washington.edu/cse331-18au-students/cse331-18au-MyCSENetID/tags

   • Click on the New Tag button on the top right corner.
   • Tag name: hwN-final (where you replace N by a number)
   • Message: HW N submission (don't skip this part)
   • Click Create tag.

   If the tag already exists and you want to move it, first delete the tag and then follow the instructions again. (CSE 331 policy states that you are not allowed to move a tag across days.)

Once you have committed and pushed the hwN-final tag, your assignment has been submitted. The staff will grade the files in your repository that are labeled with that tag.

Using a late day (turning in your assignment late)

To use a late day, just don't tag your repository on the day it is due. Be sure to tag your repository when you complete the homework, though!

Double-checking your assignment

Optionally, you can double-check your submission, using the following two steps.

1. Ensure that your code passes the validation tests. There are multiple equivalent ways to do this, so it is enough for any one of them to work (in case of flakiness in the CSE computer systems).
   • Run on attu: ./gradlew validateRemote
     and examine the output on the terminal.
   • Run on attu: git pull && ./gradlew checkNoUncommittedChanges checkNoUnpushedCommits validateWorkingCopy
     and examine the output on the terminal.
   • Have a passed GitLab runner result. Browse to https://gitlab.cs.washington.edu/cse331-18au-students/cse331-18au-MyCSENetId/pipelines

     Here is an example of your code passing the validation tests (note the GREEN checkmark):

     
     On the contrary, here is an example of your code failing the validation tests (note the RED X mark):
     
2. Ensure that GitLab has the hwN-final tag by browsing to https://gitlab.cs.washington.edu/cse331-18au-students/cse331-18au-MyCSENetID/tags.

validate

Validating your code checks it for common errors, such as forgetting to commit a required file, or your code not compiling or not passing tests. Such errors could prevent you from receiving credit for your code. However, validation is not guaranteed to catch all errors in your code.

Validation happens every time you push commits to GitLab. You will receive email if your code fails validation, but no email if it passes. You may also perform validation at other times, if you wish. You may perform validation on your own computer on or a CSE-managed computer such as attu.

To validate your code, run one of these three commands

./gradlew validateWorkingCopy

Validates the version of code in your working copy. This includes files you have not yet committed.

./gradlew validateLocalRepo

Validates the version of code in your local repository. This includes commits you have not yet pushed, but not files you have not yet committed.

./gradlew validateRemote

Validates the version of code in your GitLab repository. This is the version of your code that the TAs can see.

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

The validation script tests your code against your own test suite. Your hwN.test.SpecificationTests initially contains the public test suite. However, it is your responsibility to retain those tests in hwN.test.SpecificationTests if you want the validation script to check your code against the public tests.

GitLab runner pipeline 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.

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, run `./gradlew validateRemote` on attu.
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-18au-students/cse331-18au-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).

Back to the CSE 331 handouts home page.