1   Introduction

In this document, we will introduce how COMP30023 projects are structured, and outline how

you can make the most from the infrastructure which we provide.

Firstly, some attributes and expectations:

• As per the handbook, there will be 2 projects weighted 15% each

• Projects are to be completed individually

• Submissions must be in written in C

• Submissions must compile and run on COMP30023-provided VMs, and should produce deterministic output

• Submissions will be checked for plagiarism

2   Submission

The submission process may be slightly different to what you were used to. We expect:

• Code to be submitted to your assigned Gitlab repository named comp30023-2023-project- x in the subgroup with your username of the group comp30023-2023-projects on -git   .eng.            .     .aulabunimelbedu.

• AND The full-40 digit SHA1 hash of your chosen commit to the relevant Project Assign- ment on the LMS.

Failure to complete both successfully will result in mark deductions.

Upon submitting the hash,  you should receive an automated comment indicating whether your submission is valid/reachable on Gitlab. An example success message is: Taking  commit 2e24d35658d1b552952d226f5362fa5863d09a3c  from  2021-05-19T10:21:49Z,  day  0.

Note that it acknowledges the hash which you submitted and the time of submission (given to us by Canvas).  From this, we calculate the day number:  day 0 means that the submission is on-time, day 1 means that it’s 1 day after the deadline, and so on.

We do not perform calculations on fractional days, and thus, it is up to you to consider whether it’s worthwhile to make further submissions (if submitting late).

If you have an extension, please note that we will subtract your extension from this day number when calculating your project mark.

3   Compilation

Unlike COMP20003 and COMP20007, we do not impose the usage of skeleton files or a particular project structure (in terms of files/directories). You’re welcome to use either gcc or clang, and anything in the C standard library  (libc), and POSIX, provided it works on the VM, but excluding calls to other libraries/services.

To ensure that your projects can be successfully tested, please make sure that there is a Makefile at the root of your repository, which compiles the executable(s) defined in the specification to the root of the repository also.

You’re welcome to write test cases and scripts (possibly in other languages) and use other build systems during implementation. Feel free to keep these files for the final submission.

You can, but do not have to include copies of input files in your repository, as they will be provided by the CI/marking environment.

Do not hard code file paths for test cases or files, or make assumptions about where your executable will be launched from.

4   Testing

A breakdown of visible and hidden marks will be provided in project specifications.

We will endeavour to set up Gitlab Pipelines before the release of each project. The CI (Contin- uous Integration) will allow you to test your code against visible cases and receive some limited feedback before the submission deadline.

You can access the results of automated tests by following these steps:

1. Ensure that .gitlab-ci .yml is at the root of your repository.

After placing .gitlab-ci .yml at the root of your repository, every pushed commit should trigger automated tests against your code.

2. After pushing a commit, you should see either a green tick mark, a blue pending progress indicator, or a red cross to the right of the commit information.

Click this icon.

3. On the next screen, click the icon again, and access the test pipeline stage.

4. This will bring you to the very bottom of the test transcript for the latest commit.

Note that the marks shown in the results table of the transcript is indicative of marks you will receive for visible test cases (and tasks). Please compare it with the number of possible marks indicated in the specification.

The CI will fail (with a red cross) when any visible test case fails, and you may receive an email about a failing pipeline from Gitlab.

We do not care about whether you use the CI when implementing your projects.  However,

CI usage may be taken into account when considering extensions, plagiarism, and submission- related issues.

Unless an error or alternative solution has been identified, in which case marks will be retroac- tively awarded by re-testing all submissions, marks for automated components are final. There will be no partial marks given for uncompilable or incorrect programs, nor ‘implementation effort’.

Please note that when your submission fails in CI, it will likely fail the same way in the marking environment.  Debug your program on your VM in this case.  Make sure that you’re happy with what the CI reports.

5   Reading the Transcript

Here is an example transcript.

As it’s pretty straightforward, you may want to skip this section.

5.1   Header

The header should show that the test was executed on a COMP30023 runner, and the version of the test script.

Running  with  gitlab - runner   15 . 9 . 1   ( d540b510 )

on  admin - registry  2K4zH4xy ,  system  ID:  s _ 18ccc91b5924

..$./test . sh

COMP30023  2023  Project   1  Before  Deadline  Tests

v1 ,  last  modified  23/03/23

5.2   Commit Log

Next is the commit log. The top commit is the one that’s being tested.

Commit   log:

8 ec56c2f8ced6bbcabb6a946a24ef50d3f9d9278 :   Remove   strip .

9544 fc6320a3c26672147d31f8112c8e1315b90c :  feat:  -e   optional

5.3   Compilation

The compilation process will then be shown.  If you’re missing marks for build quality, please look to this section.

Common issues:

• make  clean is not implemented, or fails with non-zero status code

• There are dirty files committed to the repository, or make  clean is non-functional

• Running make does not produce the required executable

• Code files were marked with executable bit, use chmod  -x  <file> to remove