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:
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Track the progress by clicking on the Jobs tab towards the
bottom of the page as circled in blue in the following image:
- Click on the Job ID for the build; it will be a large number
with a
#
in front.
- 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.
- 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.
- 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.
- 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.
- 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).
- Fix your code again by getting rid of the error you introduced and
check that the build passes in GitLab.
- 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:
- Create an evidence document with the following materials in the
specified order:
- Your name, the date, and the assignment name
- The address of your project in GitLab; for
example,
https://gitlab.com/se3800f22/triangle_hasker/
- The first screen shot you captured showing the Pipelines output for
the successful build.
- 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.
- The second screen shot you captured showing the output of Docker on
this failed build.
- The third screen shot you captured showing the sequence of builds
on the Pipelines status page.
- 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.