Contents:

Introduction

You turn in your assignment by committing and pushing to your Gitlab repository, including pushing an appropriate hwN-final tag to mark the final commit for assignment N. While this is sufficient if all is well, we strongly recommend you then validate your submission to avoid drastic problems where you do not submit your homework correctly.

validate

Validating your code checks it for common errors, such as the code you checked in not compiling correctly 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.

You should validate your assignment by running ant validate on attu (and making sure that it completes successfully!) using the commands below. The idea is to make a complete, fresh copy of your CSE331 GitLab repository in a new, empty directory on attu, then run ant validate on 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.)

First, you will need set up an SSH key on your attu account, just like you had to in Eclipse on your local machine. To do this, visit the GitLab SSH README and follow the directions on that page. After you complete this step, you should be able to clone your repository. If you are prompted to enter a password for 'git@gitlab.cs.washington.edu', then this is an indication of not having configured your SSH key on attu for GitLab.

Now, to clone your repository on attu, do the following:

cd ~/
mkdir tmp   -- or some other scratch directory different from your regular CSE 331 directory
cd tmp
git clone git@gitlab.cs.washington.edu:cse331-17wi-students/cse331-17wi-YourCSENetID.git
cd cse331-17wi-YourCSENetID
git checkout hwN-final
cd cse331/src/hwN/
ant validate

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 ant validate step ensures that your implementation:

What is the result?

If validation was successful, you should see output that looks something like:


Buildfile: /homes/iws/username/workspace331/cse331/src/hw1/build.xml

validate:
     [echo] Validate checks out a fresh copy of the hw, checks for the
     [echo]       presence of required files, and runs all your tests to make sure
     [echo]       they pass.  This target can only run on the attu IWS machine.
     [echo]
     [echo]       Note: the test reports will be generated under the scratch
     [echo]       directory the validate target creates.
     [echo]
   [delete] Deleting directory /homes/iws/username/workspace331/cse331/scratch
    [mkdir] Created dir: /homes/iws/username/workspace331/cse331/scratch
     [echo] /projects/instr/13sp/cse331/username/workspace331/REPOS
     [exec] A    cse331
     [exec] A    cse331/.classpath

     ...

     [exec] BUILD SUCCESSFUL
     [exec] Total time: 2 seconds
   [delete] Deleting directory /homes/iws/username/workspace331/cse331/scratch

If there is an error, the validate script should provide some information about what is wrong:


Buildfile: /homes/iws/username/workspace331/cse331/src/hw1/build.xml

validate:
     [echo] Validate checks out a fresh copy of the hw, checks for the
     [echo]       presence of required files, and runs all your tests to make sure
     [echo]       they pass.  This target can only run on the attu IWS machine.
     [echo]
     [echo]       Note: the test reports will be generated under the scratch
     [echo]       directory the validate target creates.
     [echo]

     ...

     [exec] cleancopy:
     [exec]      [echo] Hw directory: /homes/iws/username/workspace331/cse331/scratch/cse331/src/hw1
     [exec]
     [exec] BUILD FAILED
     [exec] /homes/iws/username/workspace331/cse331/scratch/cse331/src/common.xml:106: The following error occurred while executing this line:
     [exec] /homes/iws/username/workspace331/cse331/scratch/cse331/src/common.xml:121: Could not find required file: answers/hw1_answers.pdf
     [exec]
     [exec] Total time: 1 second
     [exec]
     [exec] cleancopy.check:

BUILD FAILED
/homes/iws/username/workspace331/cse331/src/common.xml:160: exec returned: 1



This error would indicate that a required file, in this case answers/hw1_answers.pdf is missing. You may see different error messages depending on what errors are detected.

If the validate output indicates errors, you should fix them before the deadline, or you will lose points on your assignment. If validate failed because the public test suite failed, you can view a summary of the JUnit failures in your YourWorkspaceDirectory/scratch/cse331/src/hwN/test/reports directory.

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 in eclipse, fix things there, push those changes, change the hwN-final tag so it points to the last 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.test.SpecificationTests with the public test suite, it is your responsibility to retain those tests in hwN.test.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-17wi-YourCSENetID will do the job and will avoid leaving copies of your code lying around tying up space (and maybe, accidentially, visible to others).

Why does this have to run on attu from the command line?

Most ant targets that the staff supplies should work both in the Allen Center software labs and on your home computer, but ant validate only works on attu. This is because we grade your solutions on attu, so it is important to verify that your code compiles and runs correctly in exactly that environment.

Eclipse's integrated Ant support does not handle the ant validate target well. Even if you use Eclipse as your development environment, you should validate on the command line as shown above.