SE 3800: Assignment 5

50 points

GitLab Pipelines feature allows you to configure your project for CI. If you add a .gitlab-ci.yml file to your project, then GitLab will execute it on every checkin to your project. Some things you need to know about this file:

• It is written in YAML format (short for "YAML Ain't Markup Language"). The key thing to know is that the file contains a list of key/value pairs, where values can have components that are indicated by two spaces of indentation.
• The above file contains the contents

  image: docker:latest
  services:
  - docker:dind
  
  stages:
  - build
  
  build:
    stage: build
    script:
      - docker build .
  

  This file works for the types of projects you are likely to build while in school. The first line says you are using the latest version of Docker; on a real project you'd specify the version for extra robustness. The build entry specifies how to do the build, which is just executing the docker build . command you are used to using in Ubuntu. The stages entry just specifies doing the build stage; one could add additional stages for things like continuous delivery or to build multiple versions of your project.

You may work with others on this assignment, but you must submit your own solution to GitLab and Canvas.

Set up CI for your triangle classification program:

1. Create a Git repository under your folder within the se3800f22 group. Name the repository triangle_username.
   • Follow the pattern exactly, complete with underscores and a lower case username. This is important to my grading process.
2. Clone your repository on your laptop. You could do it within the Ubuntu image if you want to run cucumber; the simplest way to do that is to use the https: protocol, entering your password on every pull and push. (If you really want to use the ssh: protocol, you will want to use eval `ssh-agent` and ssh-add to activate the keys. But this is not mandatory.) But for a simple assignment like this, you can probably get away with just using GitLab to make sure things are working.
3. Copy your assignment 2 (triangle classification) solution to the new repository, ensuring that the DockerFile and source files are the top level. You might use Docker on your own machine (perhaps in the Ubuntu VM) to test that things build locally. You can improve this code if you think it is helpful, but I will not be grading the code for this assignment (other than verifying that you have multiple tests and all tests pass).
   • Warning: be careful to not copy any old .git folders to your new project! If you do copy it, delete it before adding it to the new repository.
4. Open your project in your browser so you see the top level menu like the one at the right If you see just icons on the left, you can click on a button at the bottom to reveal the sidebar.
5. Hover over the CI / CD entry (it has a picture of a rocket) and select Pipelines. Unless you have used Pipelines on this project before, you will see a generic screen with a "Get started with Pipelines" button. You can click on that button for additional information, but it's not necessary.
6. Add the .gitlab-ci.yml file at the top level of your repository and push it to GitLab.
   • NOTE: GitLab sometimes creates a default .gitlab-ci.yml file. You must replace it by the file I distribute for CI to work correctly.
7. In the Pipelines screen on GitLab, you will see that the Pipeline is running. You may have to refresh the page after the push. Note there is a Pipelines button that can be used to force running CI.
8. Track the progress by clicking on the Jobs tab towards the bottom of the page as circled in blue in the following image:
9. Click on the Job ID for the build; it will be a large number with a # in front.
10. The first 100 lines or so of output shows setting up Docker on Ubuntu. Assuming those steps have completed, you can search for "docker build" to find where it starts installing software. Normally these steps would be cached, but GitLab Pipelines starts with a blank slate each time for increased security. That means the builds take a while. In industry you would set up a CI server that integrates with GitLab so your server could cache results without possibly exposing data to others.
11. Once the Pipelines has run your full script, you can scroll down to the bottom where it shows the make clean; make test step. This is the part that is actually useful since it shows running your tests.
12. Capture a screenshot of the end of this output. The screenshot should show compiling your code, running the tests, and the message "Job succeeded." You will use it in your evidence document below. Be sure to crop your screenshots to the relevant output along with enough context that its clear what commands created that output.
13. Change your triangle classification code so that some tests fail. Remember, compilation errors are not interesting, and changing tests so that they are sure to fail is also not interesting. The goal is to show that the CI environment will catch errors if someone introduces a source error during maintenance, so simulate that by introducing an error into the classification code itself.
14. Commit the changes and capture the build output showing that the test failed (showing that the code compiles but that one or more tests failed and that Docker reports a failed build).
15. Fix your code again by getting rid of the error you introduced and check that the build passes in GitLab.
16. Browse to the Pipelines status page in GitLab and capture a screen shot showing the last several builds. This should show the failed build followed by the successful build, and would look something like the following:
17. Create an evidence document with the following materials in the specified order:
    1. Your name, the date, and the assignment name
    2. The address of your project in GitLab; for example, https://gitlab.com/se3800f22/triangle_hasker/
    3. The first screen shot you captured showing the Pipelines output for the successful build.
    4. A brief description of what you changed in your code to force a build error. You can describe it in words or use an image with the bad code circled.
    5. The second screen shot you captured showing the output of Docker on this failed build.
    6. The third screen shot you captured showing the sequence of builds on the Pipelines status page.
18. Submit the evidence document in PDF format to Canvas. I don't need the code because I can browse to the repository using the address you give in the document.

Debugging Notes

• If it seems like the tests are not running in GitLab's CI runner, check the Files tab and make sure .gitlab-ci.yml contains the appropriate text (see above). GitLab will auto-generate a version of .gitlab-ci.yml that does not match what you need for this exercise.