GitLab: Launching a Static Website & Running Project Pipeline

GitLab is a web-based DevOps lifecycle tool providing users with a Git repository manager and CI/CD pipeline features. GitLab is open-source with additional functionality being proprietary.

In this exercise, I will launch a static website using GitLab, and I will explore the tool in the context of CI/CD. The steps I took to first register, then create a new project, then run the project pipeline, and then to test my work.

  • A GitLab Account (register for a free trial here)
  • A credit card

I went to the Sign In/Register page on GitLab. I then registered (Image 1).

Image 1: Registering

I then had to confirm my account by verifying my email address. After doing so, I was brought to a profile welcome page, where I completed some basic profile building questions (Image 2).

Image 2: Building profile

I then created my GitLab group which offered me a Group name and corresponding URL. I was then prompted to invite other individuals to the group, which for this exercise was not needed.

After my registration process, I created my first project, which I named kevin-gitlab-project and made public (Image 3).

Image 3: Creating Project

After clicking “Create project,” I was brought to a Learn GitLab page (Image 4).

Image 4: My Project’s Page

I then needed to create our Index.html file, which I started doing by clicking “Project Information” on the lefthand side and arriving at my project’s page (Image 5).

Note that you can ignore the orangish SSH warning banner at the top, as for this tutorial we won’t need to SSH or use SSH keys to connect.

Image 5: kevin-gitlab-project Page

I then clicked “New file” (Image 6) which brought me to GitLab’s web-based IDE, and then I created an index.html file to serve as the content of our static webpage (Image 7).

Image 6: New file
Image 7: Creating index.html

I then wrote out a simple “Hello World” A.K.A. an “Aloha World” in HTML (Image 8), and then I documented the commit (Image 9).

Image 8: Aloha world
Image 9: Documenting Commit

I then needed to create another file in the repo. This new .yml configuration file shall indicate to GitLab that this repo is a GitLab Pages repo, we want a link to visit the website, etc. More specifically, this file is creating a job called pages telling the runner to deploy the website artifacts to a public path, whenever a commit is pushed ONLY to the master branch (Image 10).

Image 10: .yml configuration file

I then scrolled down to document the commit, and then I committed the changes (Image 11).

Image 11: Commit message & Commit changes

I then confirmed: I now have both files in my repo (Image 12).

Image 12: Confirming both files in repo

With that, the new project had been created.

At this point, I was ready to start running the pipeline, so I went to the CI/CD tab on the lefthand side, which brought me to my Pipelines page.

My pipeline wasn’t successfully running, so I had to troubleshoot. I noticed that in my configuration file, I named the root branch “master” instead of “main.” By renaming the branch “main” in CI/CD Pipeline Editor as seen in Image 13, GitLab started running the pipeline automatically due to the change (Image 14), and the pipeline passed successfully as seen in Image 15 and further confirmed on my Pipelines page (Image 16).

Image 13: Editing Configuration File
Image 14: Changes committed & automatically running the pipeline
Image 15: Pipeline passed
Image 16: Pipeline page further confirming passed pipeline

With that, we had run the project pipeline successfully and were ready to test our work to ensure the page was accessible.

I then opened a new browser window and typed the following:

Note that the provided webpage is in the following format:


The url brought me to the following page (Image 17), which indicates a successful launch of the static website!

Image 17: The static webpage works

Now let’s quickly check if we can continually & automatically create deployments by editing the content. To do this, I went into my index.html file and committed a new change which featured the addition of my last name in the text (Image 18).

Image 18:

Then by refreshing the webpage, we can confirm that we’ve created a continually integrating webpage because my last name is now present (Image 19).

Image 19: Continuous Integration

Overall my impression of GitLab has been very positive. Everything has been very straightforward, any issues were clearly articulated by GitLab, and the interface for continually integrating changes was simple.

Thank you for reading!

Credits: LUIT pointed me in the direction of this exercise, and Programming Liftoff’s Youtube, Episode “Create Your First GitLab Pages Site” guided me through the project.

Cloud, DevOps, Blockchain.