Contents:
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.
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.
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.
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: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: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.
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:
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.
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).