Note: Please treat these exercises also as professional work. For example, instead of "asdfg" use more meaningful commit messages like "Add acceleration feature" or "Fix #5" (you can find detailed advice in the How to Write a Git Commit Message and the Git Style Guide posts).

Initialization

In most of the exercises we use command line tools instead of IDEs, since only those can be used in a CI environment. Moreover, you can learn more this way for beginner exercises.

You will need the following software to complete the lab (these are available on the virtual machine template in the BME cloud, but you can use your own machine too):

• Java JDK 11 or newer
• Git command line
• Apache Maven 3.6.0 or newer
• A simple IDE like Visual Studio Code

Important: If you use your own machine, then check that Java JDK is configured correctly: use JDK and not JRE, set PATH and JAVA_HOME (see here in details).

java -version
javac -version

In these exercises everyone will make the same extensions and fixes on the same example open source project. Therefore, instead of the traditional method (creating a fork), everyone will make their own repository with the same initial content as a basis for further work.

1. [local] Start the virtual machine suggested by the instructor.
2. [web] Read the README of the example project to work with.
3. [web] Create a public repository named ivt-lab under your own GitHub user and initialize it (Initialize this repository with a README). You will use this repository for the rest of the exercises.
4. [local] Create a local clone of the remote repository on the virtual machine (using the git clone command).
   • Note: the local repository does not need to be initialized (git init)!
   • Note: after cloning, go to the ivt-lab folder (cd)!
5. [web/local] Download the content of the example open source project as a ZIP file.
6. [local] Extract the ZIP file and copy the content of the ivt-lab-master folder into your local repository (the folder itself is not needed!).
7. [local] Check which files are not tracked currently (git status).
8. [local] Add each new or modified file to the index (git add).
9. [local] Commit the result (git commit).
   • The git commit might complain at its first execution that the user name and the e-mail is not configured. This can be done with the commands git config user.email "you@example.com" and git config user.name "Your Name".
10. [local] Push the modifications to the remote (GitHub) repository (git push).
11. [web] Check your online GitHub repository, whether the files appeared!

CI exercises (GitHub Actions)

The purpose of this subtask is to build and test the project in your own repository using GitHub Actions.

1. [web] Go to the project repository on GitHub.
2. [web] Click the Actions tab.
3. [web] Choose 'Java with Maven' from the proposed workflows. A new editor will open with the maven.yml file that is created based on the workflow's template.
4. [web] Change the yml (YAML) file to use JDK 11 for building the project. You can look up the syntax in the referenced page.
5. [web] After you have finished, commit the file using the 'Start commit' button. This will trigger a new run for the workflow.
6. [web] Check the output of the executed workflow on the Actions tab (click on the name of the commit for the log files, search for the 'Build with Maven' step inside the build job). If you completed everything, then the project should compile, but one of the tests fails (see the next exercise).

GitHub Flow exercises

GitHub Actions should report an error in a unit test. This error is caused by a function that is not completely implemented (the ALL firing mode of the torpedo). The purpose of this subtask is to fix this error in a GitHub Flow.

1. [web/local] Examine the output of the CI build and the source code to see the cause of the failing test.
2. [web] Define the new function to be implemented precisely using an issue on the web interface for your GitHub repository.
3. [web] Create a new branch for development.
4. [local] Download the changes from the remote repository (git pull) and switch to the previously created branch (git checkout).
5. [local] Implement the feature and test it locally (mvn test).
6. [local] Commit and push the changes to the remote repository (git commit, git push).
7. [web] Create a pull request on the web interface of your repository for the you changes made previously. The text of the pull request should include the phrase "Fix #1", which indicates that this will fix issue number 1.
8. [web] Examine the pull request and if it looks fine, accept it, merge it into the master branch and delete the development branch. (We will see the reviewing possibilities provided by the pull requests in the next lesson.)
9. [local] Download the changes from the remote repository and inspect them using the command git log.

Further information:

• Mastering Issues
• Understanding the GitHub flow

Creating a merge conflict

1. [local] Create two new branches (with names branch-A and branch-B) locally using the command line.
2. [local] Switch to branch-A, edit a line of a file and commit the change.
3. [local] Switch to branch-B, edit the same line of the same file and commit the change.
4. [local] Switch to the master branch and merge the branches one after each other. Check the result of merging, resolve the conflict and commit the changes that happened during conflict resolution.

Finishing up

Commit every change, push it to the remote repository and check that the CI build is successful.

Do not delete your remote (GitHub) repository as it will be used in the subsequent lessons.