TP 4

Continuous integration, dynamic players and project visibility.

Meta

• Deadline: Apr. 19th, 11:59 PM
• Submission: GitLab
• Teams: Teams of three students, same teams as previous TP.
• Late submission: Not possible. You will be graded by whatever content is on your master/main branch at the deadline

It is your responsibility to submit code in a timely manner. Do not wait until the last minute, GitLab may fail.

Learning goals

In this last TP, you'll turn your Skyjo project into a presentable application, that you can put on your CV or portfolio. This last step is shorter than the previous TPs, but it will help demonstrate your versatility with advanced tools and practices in software engineering. The goal is to use CI and documentation techniques to bring your project into polished state - this way people interested in hiring you can be easily convinced of your skills.

More concretely, in this last TP, you will...

1. Complement your functional code with a CI pipeline.

2. Your CI pipeline must rerun all previously introduced maven code quality verifications.

3. Your CI pipeline must support rolling documentation releases on dedicated webpage (HTML).

4. Your CI pipeline must support rolling binary releases on a download page (JAR).

5. Support dynamic games

6. arbitrary player names

7. arbitrary (valid) amount of players
8. automatic substitution of specific player names with robot players

Step-by-step overview

1. Corrections: Check your previous submission.
   • Use the feedback returned to you on GitLab (may still take a few days, you can already re-run your tests).
   • Fix any issues, especially failing tests. Use the debugger.

2. Add a project documentation page:

   • Add a README.md serving as a human-readable entry point.
   • Make sure it links documentation, binary download, and documents how to use your software.

3. Establish a useful CI pipeline:

   • Configure automatic rerun of all maven code verifications.
   • Configure rolling documentation releases.
   • Configure rolling jar releases.

4. Modify your launcher to allow arbitrary games.

   • Support dynamic player names and amounts.
   • Support robotic players (at least Keksli and MadMax).

Detailed instructions

Check your previous submission

• Update to final interfaces and tests:

  • Interfaces:

    <dependency>
        <groupId>ca.uqam.info.max</groupId>
        <artifactId>skyjo-interfaces</artifactId>
        <version>tp4-03</version>
    </dependency>
    

  • Tests:

    <dependency>
        <groupId>ca.uqam.info.max</groupId>
        <artifactId>skyjo-tests</artifactId>
        <version>tp4-03</version>
    </dependency>
    

• Make sure all tests succeed, including the newly added game ending scenarios.

Documentation

• The first thing people see when navigating to your project is the README.md.
• A good landing page should present interest and usage of your application, without overwhelming the user.
• Add or edit the existing README.md, and create at least the following sections:
  • Project name
  • Project context
  • Link to documentation (see CI section)
  • Link to JAR download
  • Run instructions, i.e. how to launch your JAR
  • Contributors

CI

• CI is the way to go to ensure consistent code quality. You'll configure your CI pipeline to rerun all quality checks already enforced by maven.
• Add a custom, non-default maven build profile named nomutation that skips mutations tests. The CI pipeline should exclusively use this profile, to speed up the pipeline.
• Good software has accessible documentation. You'll enable a pages job to store the up-to-date javadoc of your code on a dedicated webpage, linked from the README.md.
• Good software supports rolling releases. You'll reuse the pages job to also store the working JAR file of your application on a dedicated URL, linked from the README.md.

Launcher

• So far the launcher code always started the same game, with the same players.
• Modify your code to accept player names as arguments, i.e. java -jar Skyjo.jar Max Ryan Hafedh. (2-4 players must be supported)
• Modify your code to automatically substitute robot players, i.e. if a player name is Keksli or MadMax, the player must be substituted by a corresponding AI instance.
• If you have implemented your own AI / robot player, you can reserve additional player keywords for your AI.

Grading scheme

Criteria	Max percentage
All tests pass	15%
All previous code quality metrics respected in pom (mutations, coverage, checkstyle, complexity, javadoc)	25%
CI	25%
Dynamic game configuration supported via runtime arguments	15%
README + working links to javadoc and JAR	10%

Recommendation

Simulate the grading process before submission: Re-clone your own project and run mvn clean verify and ensure your project can be built without warnings or errors.

Desk rejection

Here is a checklist of what to avoid at all costs. If at least one item of the checklist applies, your submission will lose all code-related points. There may be other criteria for desk rejection.

• Solution not provided in dedicated GitLab directory, or not on main branch.
• Solution is distributed across multiple branches.
• Repository contains zip file.
• Code does not compile with provided maven command.
• pom.xml has other plugins or dependencies than allowed.
• Provided classes do not implement provided interfaces.
• Implementation of abstract test classes is not provided in test package.
• Project structure has been altered / is not respected.
• Program attempts network communication at runtime.
• Program stalls at runtime.

MISC

This section provides additional resources for the technical realization of your TP.

Sample games

• TP3 contained no integration tests reaching the game end.
• Below you find the log filed for three additional test scenarios reaching game end.

Files

Iterations	Players	Traces file
61	Keksli VS Keksli	keksliColEliminationEnd.txt
82	Keksli VS Keksli VS MadMax	keksliVsKeksliVsMadMaxEnd.txt
144	MadMax VS MadMax	madMaxVsMadMaxR43End.txt
445	MadMax VS MadMax VS MadMax VS MadMax	madMaxQuadrupelR51End.txt